We did defer it as long as possible until 1 or 2 days ago and we dropped that again.
Because it is almost not doable and it is currently not very easy to make a completely
stateless website with wicket anyway.

But that is just the default behaviour. You could if you want make youre own ISessionStore and
delay the creation of everything as much as possible. I guess we need then some tweaks to that interface
because the pitty thing is that you can't already ask the sessionid of the request without making the session.
or you have to set youre own cookies...

If you want a really stateless page/site. Then everything must be bookmarkable/mountable links..and you can't use our
form components you have to do the submit to a bookmarkable link again and work with PageParameters to
get the values from the request. I hope to improve that in the next version of wicket. To introduce a
BookmarkableForm. That points to a bookmarkable pages that is first getting constructed and then
populated the same way as it does now. you can't keep state then ofcourse (so you only have the initialstate of
the page. but this is fine for search box or simular things)

But we still have the session object where you could put something in and that one also has to be stored..
so if the session would be dirty anyhow with the first request the session would be created.
then we have the default pagemap if you create a page (don't know at that time if it is bookmarkable or not)
then the page gets an id that is taken from the pagemap and the pagemap is dirty so on the first request
the pagemap will try to store itself becaue it needs to hold the state that it incremented its id.
But these 2 default objects are small and don't have a lot of overhead in the session

we had a discussion if we could have jsessionid in the url or cookie for bookmarkable urls but we have to
do it else you loose the connection to a session object (with a logged in user or something like that) if you
click on a bookmarkable url with cookies disabled.

johan


On 4/11/06, Michael Day <[EMAIL PROTECTED]> wrote:
Hi,

We have been discussing this quite a bit on IRC, but I want to bring
it to the list for more exposure.  As far as I understand, wicket
currently has a concept of "stateless pages", which are pages that
are not stored in the session.  Unfortunately, there is no way to
avoid session creation on the very first hit.  This means that any
user hitting your application will be assigned a sessionid.  This is
very bad because for a couple of reasons:

1.  Search engines obviously don't like sessions and they don't
support cookies.  This prevents your site from being crawled and
indexed properly.

2.  Performance - creating a session means that it must be serialized
in a cluster (even if there is no data?).  Why do this when there is
no technical justification?

With the recent changes regarding PageMaps, is it possible to defer
session creation until a user hits a stateful page?  If not, then
wicket cannot be used for public web sites (news, online store, etc)
that need to be indexed in today's search engines.

Thanks,

Michael Day


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Reply via email to