I checked the code and see what you mean. Side note: Some months ago we discussed about separating resolve and render into two phases until Johan found the different redirect strategies which were solving the same (cluster) problem, the separation was meant to solve. Separating resolve and render requires significant changes to core and is probably something for version 2.
A dirty solution: On pages we have BodyContainers automatically attached to <body> to support onLoad attributes. Assuming we extend BodyContainer to render a arbitrary list of components (Javascript) at the very end, prior to </body>, we make sure it allways rendered last (no more time dependency). Currently I can not think of another solution. Juergen On 8/15/05, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > A am trying to fix the DatePicker so that when the component it is > attached to (typically a TextField) allready has an id (HTML id that > is), I leave it as is instead of allways overriding it with a generated > id. For the field, I can simply do that by implementing the > AttributeModifier. The problem though is that I need to know about this > id when I generate the JavaScript initialization code. The only way I > could do that now I think is to let the attribute modifier pass the info > somehow to the initialization code. However, that would create a time > dependency - which is very fragile - that would depend on the component > with the attribute modifier attached being rendered before the component > that uses the initialization script. My problem would be solved if I > could access tag info of components before the actual rendering process > (in which the attrbute modifier takes part) happens. > > Eelco > > >not sure I understand why you need to know markup information before > >it is rendered. Subclassing render or onRender() and thus having > >access to the markup information at the earliest possible time is no > >solution? There is not much that happens between resolving the > >component (assoicate it with the markup) and start of the rendering > >phase. > > > >Juergen > > > > > >------------------------------------------------------- > >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-develop mailing list > >[email protected] > >https://lists.sourceforge.net/lists/listinfo/wicket-develop > > > > > > > > ------------------------------------------------------- > 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-develop mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/wicket-develop > ------------------------------------------------------- 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-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-develop
