Hmm.. I am still evaluating if Wicket is worth the trouble. I've been reading about how Wicket stores the object model in the session, making each user session potentially quite large, which doesn't bode well at all for session replication performance. I have read about detachable models, which I assume means instead of each user session storing object data, for example form input values, label strings, etc, you can pull the data from a database when a request is made.
It seems odd that it's so difficult to access a page that is either all or mostly html, with some links to navigate to other pages. I suppose I don't know enough about how to configure wicket. I have a login button that ideally will use wicket to log in, and several "logged in" user pages with data, tables, form input, etc. But the majority of the outside (not logged in) site is static content with the occasional link to another static page or sometimes a page with some form data. I haven't found any info that explain when to use Wicket and when not to in a typical web application where many pages are static content with links, and then there are those dynamic pages for logged in users or a shopping cart or form registration. As of now we're using Struts2/jsp pages with page includes to reuse the header/footer area. I wanted to use just Wicket for the whole site, but with what at least seems to be complex just to view a page, and the session memory usage, I am a bit scared now. The learning curve seems a bit steep, I have been using MVC for so many years.. when I read about Wicket and picked up the book it just seemed like a more separated OO way to approach a web app. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Having-problems-with-wicket-pages-not-showing-up-tp3784941p3785097.html Sent from the Forum for Wicket Core developers mailing list archive at Nabble.com.
