what you want might be more intuitive, but it would not be cheap at all. you're basically requiring construction of every page that is linked to when you load a given page. and if you link to 50 pages in a page's navigation, you'll wind up constructing them all... and not only that, but you have to do this /for each page you render/... what's more this all has to be in wicket's session and potentially replicated across the cluster. this means that suddenly wicket can't have just a stack of 10 pages for each session for backtracking... it has to potentially store hundreds of page objects, which cannot be made to be nearly as lightweight as PageLink. furthermore, some of these unpopulated page objects may or may not need to be unique and further complications would arise there.
anyway, i don't think this really works out at all... while it would be easy to make this pattern possible, i think it would lead to exactly the opposite of what you suggest... absolutely horrible performance and all kinds of problems... not to mention a major rewrite of the core. i spent lots of time thinking this through 9 months ago and i actually took the feature you suggest out because i don't think it works and i didn't want to encourage the usage.
Gili wrote:
If the page was populated at rendering time (only the first time rendering happened), as opposed to construction time, you could getPage() very cheaply and invoke getClass() on it to get the equivilent of getPageClass(). The point is, we could/should defer any operation until it's actually needed. It'll improve Wicket's overall performance. This is just a simple example of how it would help...
Gili
On Fri, 28 Jan 2005 09:35:00 -0800, Jonathan Locke wrote:
i don't understand.
Gili wrote:
First, let me say that getPageIdentity() is indeed better. Thank you. I would like to continue investigating some ideas, though, so please bear with me...
On Wed, 26 Jan 2005 13:17:24 -0800, Jonathan Locke wrote:
stop and think about this for a minute. if you instantiate the page you're linking to, all *its* links would have to instantiate *their* pages... and so on... for most sites, you would wind up instantiating every page on the site since they are all connected. delayed linking is a core design of wicket and is not something that will ever go away.
I am asking for delayed linking to go away. I am simply saying we should investigate going further with lazy loading.
Why not defer adding children (such a links) to a Page until render-time? I mean, right now we add() in the constructor of a Page whereas we could separate Page construction and Page configuration. You'd invoke Page.init() -- or whatever you decide on calling it -- the first time a page gets rendered. This way you wouldn't end up populating parts of the model unless needed. This would benefit IPageLink and perhaps other mechanisms in the future that want to get at model information without actually rendering the whole thing. It might also help reduce memory usage.
Gili
------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ Wicket-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-develop
------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ Wicket-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-develop
------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ Wicket-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-develop
------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ Wicket-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-develop
