I don't believe in a cookie and or url state what is that? storing a page in an url?
We have a branch where we have a first draft of ClientSide Page saving (in an _javascript_ variable that is then set in a hidden field of all the forms)
https://svn.sourceforge.net/svnroot/wicket/branches/clientpagestate/wicket
And pagemaps are pretty much useless when saving on the client side
What do pagemaps do then? completely nothing. The only thing left is generating the pageid. and some methods that redirect calls to the session(store)
In the branch there the pagemap is really gettin in the way. We need to take them apart (BasicPageMap > AccessStackPageMap (the last is pretty much what we have now)
We already tried to have a ISessionStoreLocator/Creator that didn't work to well and it was not that nice to work with.
It is also would be only usefull if you want to do 2 different things based on the session/information in the request?
Then it would be ok. As long as the SessionStore doesn't get state of the current session/request.
Making a database session store is very very easy at the moment. That can be done in a few lines of code now in the current wicket code.
johan
On 4/29/06, Jonathan Locke <[EMAIL PROTECTED]> wrote:
i saw this thread on wicket-user today and wanted to comment on
client-side state.
i think the right thing for wicket is to support a generalized interface for
storing session state. it could be that the existing ISessionStore interface
or some modification of it is sufficient. but whatever the interface, all we
need to do is start providing pluggable implementations. the possibilities
are endless, but a few include:
- HttpSessionStore
- ClientPostBackSessionStore
- CookieSessionStore
- UrlSessionStore
- DatabaseSessionStore
and so on... this should be very straightforward and elegant to do with our design.
it could also be that a re-think of the ISessionStore interface would help to make
this more elegant. without really thinking it through, i'd say it might look more like:
public interface ISessionStore
{
PageMap newPageMap(String name);
PageMap getPageMap(String name);
List<PageMap> getPageMaps();
IPageMapStore getPageMapStore(PageMap);
}
public interface IPageMapStore
{
void setPageMapEntry(IPageMapEntry entry);
IPageMapEntry getPageMapEntry(int id);
}
probably the same object would implement both interfaces. and then
the ISessionStore interface would be retrieved by an overridable method
in application that returns:
public interface ISessionStoreLocator
{
ISessionStore forRequest(Request request);
}
probably that could be implemented by the same object in many cases too.
this would get rid of all the dependencies on unabstracted concepts like
"attributes".
jon
