ehmmm i dont think this will really work quite right for the most ajax calls. Because the page that is constructor is really in the constructed state So for this to work you have really store the state of the page somehow everytime you do an ajax request.
How is that different from reconstructing to handle e.g. a call to a link? It's the same thing in the end, as behavior listeners are just one extra indirection from components.
And if there are quite a lot of ajax request for a pretty big page. I wouldn't want to construct it everytime (and fully initialize it)
Johan! Premature optimization! Don't be so sure before having measured it. I *expect* it to be not too bad; the component tree of a typical stateless page probably has just a few components (and behaviors) on them. But ok, let one request result in hundred objects being created. So what? See what one Hibernate query generates for instance. Nah, I don't think it's a big deal, and more importantly, as long as it linearly scales and is useful it is ok even if it would be more expensive.
Yes this could work but then Session is really not thread save! Now it semi safe (except for the attach/detach methods)
Sure. That's not a big concern though. We have to synchronize pages for various reasons, and protecting the session state wasn't the first and greatest of them, especially as other framework don't do that in the first place. It's something we can explain to our users and a pretty obvious 'limitation' if you ask me.
For this we just can remove the Session lock object from the RequestTarget. Because all else are already stopped at the Session.get page call.
Great, let's do that!
* I think it opens the way for comet style behaviors. i think comet style works much better on session pages.
I think not as the session would be locked while the comet thingy is in progress (which may be indefinitely). So it's actually quite the opposite: you can't really properly do comet when the session is locked. Eelco
