Reputation: 2831
I'm trying to understand how wicket's application works, I'm newer to web application design and Wicket specifically.
When wicket is deployed to a server and launched a session is given to each user from the server. What is the difference then between the server session and wicket's session? So each user who accesses the web application do all users share the same data stored in the web application until you use wicket's session? So what I mean is lets say I have a list hard coded with 6 strings, and User A goes to the URL to the application and views these six strings and decides to add a string to the list, so now there are 7 strings. User B goes to the application URL, will he see 7 strings or 6 strings?
When would be reasons to use the wicket's Session?
Thanks!
Upvotes: 2
Views: 3812
Reputation: 1806
Quote from Apache site:
In Wicket, all server side state is automatically managed. You will never directly use an HttpSession object or similar wrapper to store state. Instead, state is associated with components. Each server-side page component holds a nested hierarchy of stateful components, where each component’s model is, in the end, a POJO (Plain Old Java Object). Wicket maintains a map of these pages in each user’s session. One purpose of this page map (and the component hierarchy on each page) is to allow the framework to hide all details of how your components and models are accessed. You deal with simple, familiar Java objects and Wicket deals with things like URLs, session ids and GET/POST requests.
To sum up, Wicket objects and Wicket sessions store their data in a specialized data structures which uses regular sessions to serialize themselves. Wicket way of using sessions abstracts the old method to benefit from server side stateful UI objects as well as persistent data.
Edit: Mixing the two or coding your own abstraction would be the same as inventing the wheel which Wicket already reinvented.
Upvotes: 7