On 2/14/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
> 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.
those stateless links are also very limited use.. Because only the state that the construction of the page has is valid You can really only use this for navigation StatelessForms are different, those have there usages because the data that is important is posted. But what kind of ajax behaviors do you have in mind? Things like FormComponentUpdatingBehaviour is ofcourse useless in a stateless fasion. AutoCompleteBehavior? Also the page should also exactly reconstruct itself exactly the same. So also after the ajax click or event. Because with ajax we don't rerender the complete page. But only parts. So it could be that something that is still displaying on the page is not completely correct again. In a normal stateless link this is not a problem because the page is fully rendered again with all the latest data en component tree.
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.
One thin i compare it with is the App1Test1 that was in the beginning wrong. It did fire the wrong urls to the servlet. That resulted in that for every request the home page was created instead 2 homepages created and 3 link requests (with 1 that does a rollback!) And when if fixed the urls. The test where going much much faster. The only thing that changed that there wheren't 5 but only 2 pages created!! That did make a big difference. But one big plus for complete stateless is that the pages are not serialized at all so that will gain big time again.
> 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!
then we really have to check our own session code but we could try it.
* 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.
No it will work fine as far as i know now how for example Jetty works. Or the continuations of rife. But i don't know what the real comit "standard" is. All of them uses an exception to "end" the request and keep the connection open at the lower level (in the container) so more a http keep alive thingy. johan
