I think what I am asking for and what should be clarified in the documentation is what are the "best practices" in terms of when to initialize the structure. You might be right that technically speaking I may inject my code into any of these methods but I am looking for something that is sanctioned by the documentation. I'm also expecting this to be consistant across all components, so this should work the same for Page as any other component.
Do I need to file a RFE for this?
Gili
Juergen Donnerstag wrote:
checkAccess() is called per Page after intialization. Though meant for access check, it can serve your purpose as well. And IMO there are even more: onRender, onComponentTagBody etc.
Juergen
On Wed, 23 Mar 2005 12:49:15 -0500, Gili <[EMAIL PROTECTED]> wrote:
But Page has no onBeginRequest(). What do you do then?
Gili
Jonathan Locke wrote:
there is no need for this. there are already two phases of init before the rendering cycle. you can override onBeginRequest to perform extra initialization if you really need to. but 99% of the time you won't even need to do this...
Gili wrote:
The biggest problem I currently have (related to this issue) is that I manipulate the sturucture -- calling add() -- in the constructor but this requires me to get call getApplication() and getPage() at certain points and this isn't actually available yet.
It would be good to move to a no-arg constructor, formal structure building method (should be called after the user has add()ed the component into the parent, so now it is available), and *then* a rendering phase.
Gili
Juergen Donnerstag wrote:
+1 for change. But I've currently no time to do it. Someone else has to.
Juergen
On Tue, 22 Mar 2005 10:49:53 +0100, Christopher Turner <[EMAIL PROTECTED]> wrote:
Maurice, Yes, I agree that it doesn't solve every single case. However, the most common place that lazy loaded collections will be used is in list views and thus building the structure prior to rendering solves the most common case that I have encountered. For the much smaller number of cases where this is not the case then I'm quite happy to pre-initialize any lazy loads that I know I am going to need for the current use case.
regards, Chris
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: 22 March 2005 09:12 To: [email protected] Subject: RE: [Wicket-develop] major rendering phase change
+1 for the change too.
Sorry Chris but what you are saying here does not make sense to me.
In the rendering your model is going to get accessed, this model may contain a lazy loaded collection. So you still need to have the hibernate session running at rendering time.
Unless you would have accessed the lazy collection before, causing it to load, but in order to do that in a generic way you would pretty much have to copy the behavior of rendering (without writing to the output stream) and that would (I m o) be wrong.
I you see things different let me know.
Maurice
-----Oorspronkelijk bericht----- Van: Christopher Turner [mailto:[EMAIL PROTECTED] Verzonden: dinsdag 22 maart 2005 10:00 Aan: '[email protected]' Onderwerp: RE: [Wicket-develop] major rendering phase change
I'm +1 for this change having already discussed it with Jon previously. I think the decoupling of making the structure of the page from the rendering also has some other advantages. On particular I can think of right away is that Hibernate lazy loaded collections are easier to use as you don't need to keep the session factory/transaction active for the whole rendering process.
Regards, Chris
given a particular problem in versioning and some anticipation of a horde of other problems, i think we need to change our model for rendering components a little. eelco and maurice verbally agree, but we'd like any feedback from the list too. the versioning problem is that urlFor() can be called during rendering to create a url of version N. if a component further down the page makes a structural change while rendering, it will increase the version at that time, resulting in urls further down the page having version N + 1. the root problem here is one that chris and i wanted to fix some time ago and one that seems worth fixing: once rendering begins, the component hierarchy should be immutable. any attempt to change the structure during rendering would result in an exception. to implement this change, we'll have to change ListView (yet again... sorry juergen!!) so that it has a component building (populate) phase and a render phase which are decoupled. i think this is a really good change, but i could be missing something too... does anyone see any problems with this? jon
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396> &op=click _______________________________________________ Wicket-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-develop
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Wicket-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-develop
------------------------------------------------------- This SF.net email is sponsored by: 2005 Windows Mobile Application Contest Submit applications for Windows Mobile(tm)-based Pocket PCs or Smartphones for the chance to win $25,000 and application distribution. Enter today at http://ads.osdn.com/?ad_id=6882&alloc_id=15148&op=click _______________________________________________ Wicket-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-develop
------------------------------------------------------- This SF.net email is sponsored by Microsoft Mobile & Embedded DevCon 2005 Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows Embedded(r) & Windows Mobile(tm) platforms, applications & content. Register by 3/29 & save $300 http://ads.osdn.com/?ad_id=6883&alloc_id=15149&op=click _______________________________________________ Wicket-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-develop
------------------------------------------------------- This SF.net email is sponsored by Microsoft Mobile & Embedded DevCon 2005 Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows Embedded(r) & Windows Mobile(tm) platforms, applications & content. Register by 3/29 & save $300 http://ads.osdn.com/?ad_id=6883&alloc_id=15149&op=click _______________________________________________ Wicket-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-develop
------------------------------------------------------- This SF.net email is sponsored by Microsoft Mobile & Embedded DevCon 2005 Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows Embedded(r) & Windows Mobile(tm) platforms, applications & content. Register by 3/29 & save $300 http://ads.osdn.com/?ad_id=6883&alloc_id=15149&op=click _______________________________________________ Wicket-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-develop
------------------------------------------------------- This SF.net email is sponsored by Microsoft Mobile & Embedded DevCon 2005 Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows Embedded(r) & Windows Mobile(tm) platforms, applications & content. Register by 3/29 & save $300 http://ads.osdn.com/?ad_id=6883&alloc_id=15149&op=click _______________________________________________ Wicket-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-develop
