i work on an application that is mostly panel driven as well, albeit we do not use that much ajax _yet_. so there is definenetely nothing wrong with this approach, any component hierarchy goes.
if there are problems with 2.0 supporting this then they should be addressed, feel free to open jira issues. -igor On 2/6/07, Jan Vermeulen <[EMAIL PROTECTED]> wrote:
We are currently building an application in Wicket (2.0) that has only a single page: that page contains a border where template markup is defined. The body of that border is a panel that gets replaced while the user navigates through the application (something similar to the wizard implementation in Wicket, but without having created all wizard panels from the start). Advantages: * we use Ajax requestTargets that only replace the changing part of the page: less flicker, less network traffic. * as a templating alternative (compared to the extension templating mechanism), it allows for the body of the template NOT to be an extension of the template page. * if the action is limited to an smaller part of the page (f.i. a modal dialog), same logic applies. Problems with Wicket: * the SecondLevelCachePageStore is 'page-oriented': while I remain in the same page, nothing gets flushed to disk. * the UndoVersionManager is maintained in the page, and so its changeLists are using up memory as long as that page is not serialized to disk. I am aware of the open discussion on refactoring of the pageStore & versionManager: the 'single-page application' is an extreme case of the 'replace-component' syndrome (cfr. http://www.nabble.com/refactor-storing-pages-and-versions-tf2943670.html#a8231263 ). * since the last change in Wicket 2.0 with 'mergeversion' in the UndoVersionManager, all Ajax requests are by default considered as candidate for merging to the actual version i.s.o. creating a new version. This is a good idea for changes applied to the same page. But in our case, page navigation is also done through ajax requests, and here we clearly want a new version for these requests. We solved this problem overwriting the Request.mergeVersion() method. But we felt that there might be a more generic need to differenciate between ajax requests that require merging and ajax requests that require a new version. Did we take the wrong approach ? Or should Wicket be better prepared to handle a lot of ajax modifications to the same page ? -- View this message in context: http://www.nabble.com/Single-page-applications%3A-bad-idea-in-Wicket---tf3182341.html#a8831903 Sent from the Wicket - Dev mailing list archive at Nabble.com.
