I kind of missed this discussion as I was working on the request cycle
handling refactoring. After a short offline discussion with Johan, I
took this as part of the refactoring too. The new way of handling
(still has to be discussed with the other devs after I'm further with
it, but I think it is look much, much better now) has synchronization
depending on what I now call the 'request target' which could be
anything from a page - which should be synchronized on the session -
to shared resources or external resources (like images from your web
app directory) - which shouldn't be synchronized at all.

The Session.updateSession thingy is planned for step 2 of the
refactoring. Ultimately, I'd like to end up with something that would
allow for 'sessionless' applications. For instance, while working with
bookmarkable pages that do not hold any components that implement
IRequestListener, there is really no need to even put them in the
session. In that case, or if you would have a home page like that, I
would like to be able to at least defer creating a session object
until it is actually needed. Not sure how difficult this will be, but
it is probably doable.

The refactoring encompasses quite a lot; it touches most important
internals on Wicket, so I'd like to take a few days to sort it out and
keep really focussed and have offline dicussions with core developers
based on the commits first. So... Johan, Juergen, Igor, Martijn, ...
you know where to find me :)

Eelco


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user

Reply via email to