[Wicket-user] The other side of Wicket ...

[Ashley Aitken]

Howdy All, I've been reading more about Wicket, particularly its integration with non-presentation aspects of an Enterprise application, e.g. the application and persistence layers.   I've read about the Wicket-Spring integration, and the LazyInitProxy - where a Wicket session keeps an injected proxy to any dependencies(?).  I can see mostly how this works.  However, although others have proclaimed it so, it doesn't seem that elegant or easy to me.  I'm wondering if people think this is a good solution or Wicket needs more work in this area (not being critical, just asking)?   I must say I haven't thought much before how sessions would be managed across each request-response loop.  I believe Wicket serialises the session and all the pages cached therein.   I've worked with WebObjects and therein a session is sent the awake() message before the request-response loop begins, and the sleep() message after the r-r loop finishes.  I guess these inherited methods could include code to serialise the session, but I have never thought how they handle not serialising all the business objects (model) managed by the O/R framework. Maybe they don't serialise the session or pages but just keep them in memory.  I believe Wicket does the serialisation, at least in part, to perhaps assist with clustering (processing requests on different servers etc).   I am just wondering how other frameworks handle this problem and why it seems more difficult in Wicket? Would Wicket fit in well as a Web presentation layer for an application using EJB3 (including JPA)? Best regards, Ashley. -- Ashley Aitken Perth, Western Australia mrhatken at mac dot com Skype Name: MrHatken (GMT + 8 Hours!)