Johan Compagner wrote:
this is pretyt much all in place.
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)
How will hidden field work with ajax? Will every response have to carry
the whole (new) page state?
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]
<mailto:[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
-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
