But honestly I'm not especially in favour of this approach. Making more and more methods public IMO is not a good approach because we can not change it later on any more. renderComponent is "hidden" by purpose not by accident. IMO the smaller the public API the better. I prefer to look at the use case, find whether is it an important feature missing or not. If yes, than we have to find a solid and easy solution to solve this category of problem. What is the benefit of having 3+ means to implement a certain functionality and to implement yet another one? May be the current functionality is wrong and should be changed, but just opening the API IMO is not the solution.. Thus I'm -1 on your proposed RFE.
Juergen On 9/9/05, Simon Berriman <[EMAIL PROTECTED]> wrote: > > And there is yet another mean: you may create a StringResponse at > > the begining of component.render() (or onRender?), call > > super.render(),get the response string, depending on your requires > > prepend and append whatever you want, restore the orginal response > > and write the string to the response. > > But its not as clean as simple saying to a component "here's the > MarkupStream, go render yourself" with the single statement > "storedComponent.renderComponent(findMarkupstream());" from within the > onRender() of a component that is in the normal flow. I just like that > idea... > > -S. > > > > > > > > > > > > > > > > > <!-- ---------------------------------------------------------------- > > Come visit us at: > > Content Management Europe Exhibition. 29th November - 1st December 2005, > Olympia Grand Hall, London. Stand # 341 > > GOSS - Ranked 4th in the Deloitte Technology Fast 50 Awards 2004 and 88th in > the Deloitte Technology Fast 500 EMEA. > > This email contains proprietary information, some or all of which may be > legally privileged. It is for the intended recipient only. If an addressing > or transmission error has misdirected this email, please notify the author by > replying to this email. If you are not the intended recipient you may not > use, disclose, distribute, copy, print or rely on this email. > > > > Email transmission cannot be guaranteed to be secure or error free, as > information may be intercepted, corrupted, lost, destroyed, arrive late or > incomplete or contain viruses. This email and any files attached to it have > been checked with virus detection software before transmission. You should > nonetheless carry out your own virus check before opening any attachment. > GOSS Interactive Ltd accepts no liability for any loss or damage that may be > caused by software viruses. > > > > > ------------------------------------------------------- > SF.Net email is Sponsored by the Better Software Conference & EXPO > September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices > Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA > Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf > _______________________________________________ > Wicket-user mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/wicket-user > ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Wicket-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-user
