> - There is NO way for you to store anything in the Session other than to > have your own custom WebSession class and define the attributes you would > want to maintain...
That's the idea. Unlike the typical way of using HttpSession which is basically a hashmap, we provide a pattern that lets you (forces you to) use strong typing. Of course, if you're unhappy with it, you can provide a custom session and expose the protected set/getAttribute methods and you can use it as a hashmap again. But I don't see any advantage of doing that. When you create reusable components that need to store information in the session without knowing nor forcing the exact type of the session, there is the meta data facility (which also exists for other entities, like application). > offcourse with that also provide the implementation for > the getSessionFactory() in your Application class OR is there? that got simplified in 1.3; public Session newSession(Request request, Response response) is what you need to do to provide a custom session. > - Wicket's feature of Second Level Cache is just related to the storing of > pageMap pages on the disk (so as to save memory) it doesn't do the same for > the session objects in general ?...i am sure it doesn't..i dont its just > something out of the blue which came to mind and felt like asking.. SLCSS saves pages to second level cache, which is by default disk, but may also be a database or network or whatever you want. It doesn't store the session to disk because there is no need for versioning etc, and the session object is something you want to have immediately available anyway. Eelco --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
