> > I GET your point, but what about scenarios where one has regular objects
> > (e.g. Person) mapped as a model using CompoundPropertyModel on a page,
> > wouldnt it be reasonable to access/use the same object (which would
> > already be stored in session since its part of the page)..rather than
> > storing it seperately ? to access it at other pages..
Then you would pass either the object or the model. E.g:
setResponsePage(new AnotherPage(personModel));
or:
replaceWith(new SomeOtherPanel("myPanel", personModel));
when you use component replacement instead of page navigation.
Passing objects like that (and requiring them in page/ component
constructors) is good OO programming. Requiring your pages to know
about pages being stored in the session and containing certain objects
will get you into a mess pretty quickly.
The fact that Wicket stores pages (only the current one in fact, as
older pages are saved to second level cache, which is by default a
page file in a temp dir) should be regarded as an implementation
detail. It is completely up to the implementation of the session store
where page maps are being stored. Even the what page maps are used are
implementation details of the session store.
> > WELL i feel like there could be a lot of scenarios where one might need to
> > store things in session, just for the sake of example..like a cart in case
> > of a shopping-cart app (i know there can be other means to achieve the
> > same)..similarly there could be various other scenarios,
Sure, a shopping cart is another good example, unless the shopping
represents a really small part of your app. In the end, you decide
what you think is good for storing in your session and what is yours.
> just wondering if
> > there is a specific reason (with respect to wicket..) because of which u
> > are saying that one shouldnt store anything in the session ?
Generally, you don't want to keep objects much longer in memory then
needed. And besides that, it is just good programming practice to keep
the scope minimal; whether that applies to variables in loops or like
here the reach-ability of objects in general. It's better to keep
things as tidy as you can. And finally, if you have a page that for
instance requires a person object to be available to function right...
communicating that though requiring a person object to be passed in is
a lot clearer than expecting it's clients to put that object in the
session somewhere.
Eelco
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
