I don't agree about those pages not being stateless. They are not stateless in that the actual state of these *pages* - not their buffered renderings - is not relevant. There is no component state that we have to keep to interact with the user, the only thing we are keeping that buffer for is to trick the browser.
But... as I commented earlier, I think we can do without the buffer for stateless pages anyway, as - certainly for bookmarkable pages - there is no need for what is officialy called the redirect after POST pattern (but which in our case is also applied to GETs). Instead of just applying this pattern mindlessly to every request, we could try to be a bit smarter and only use the pattern when we actually need it. Eelco On 2/7/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > my point was that we are still storing the buffer inside the session, so the > page is not stateless. the buffer might be an optimized view of the page, > but that can be achieved cleaner by optimizing using IPageMapEntry. > > > -Igor > > > > On 2/7/06, Johan Compagner <[EMAIL PROTECTED]> wrote: > > just the buffer is much much lighter as the whole component structure and > all the models. > > And it is very fast in serving again to the outside world. > > And we only have to keep it when it is redirected to. Not when that > doesn't happen. > > > > But if that is not satisfying then we just have to drop it for that case > yes. > > > > > > > > johan > > > > > > > > On 2/7/06, Igor Vaynberg < [EMAIL PROTECTED]> wrote: > > > but keeping the buffer is the same as making the page stateful, so why > not drop stateless pages period. > > > > > > -Igor > > > > > > > > > > > > > > > On 2/7/06, Johan Compagner < [EMAIL PROTECTED]> wrote: > > > > i don't see how. > > > > Why would that fix a problem to always redirect? A redirect is the > problem. > > > > And most of the times when a bookmarkable url is hit we don't redirect > at all and that is good and then there is no problem when there are > stateless. > > > > > > > > For example if you would use ONE_PASS_RENDER as the strategy it pretty > much almost always works. Because the url that builds the page > > > > is always in the browser (when you don't set a redirect youreself in > the code) so that a refresh works. > > > > > > > > So Bookmarkable urls that render a page which is stateless is fine. > > > > setting a response phase in an onClick or onSubmit and don't redirect > works fine if that response page is stateless. > > > > > > > > There just can't be any url with path=x (our Page.urlFor() test) or a > redirect url to a page. That just makes it statefull. > > > > We just can't make every stateless pages a bookmarkable one because we > don't know that the page can have state to construct it right. > > > > > > > > the only option i see is to keep the buffer of the page when a > stateless page is redirected to. > > > > > > > > > > > > johan > > > > > > > > > > > > > > > > On 2/7/06, Igor Vaynberg < [EMAIL PROTECTED]> wrote: > > > > > well what we would have to do is always perform a redirect if we see > a stateless page as the response target to a bookmarkable url. wouldnt that > fix the problem? > > > > > > > > > > > > > > > -Igor > > > > > > > > > > > > > > > > > > > > On 2/6/06, Johan Compagner <[EMAIL PROTECTED]> wrote: > > > > > > the problem is that that would be hard. > > > > > > A page can be stateless because of no call backs or what ever > > > > > > But it could be constructed with data that you only have on > construction time > > > > > > > > > > > > For example the Exception page of wicket. > > > > > > That is a stateless page (no call backs) but it is redirected to, > so after a refresh it goes wrong. > > > > > > How would you catch that page in a bookmarkable url? > > > > > > > > > > > > setResponsePage(new StatelessPage()) is only a problem when it is > redirected to. If for example that happens on a Link.onClick() or > form.onSubmit() > > > > > > that doesn't redirect then there is not problem. > > > > > > > > > > > > johan > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 2/7/06, Igor Vaynberg < [EMAIL PROTECTED]> wrote: > > > > > > > i commented out Page 729+730 so that anytime a page's urlfor is > called it becomes stateful. > > > > > > > > > > > > > > the problem is that the url becomes session relative when you do > setResponsePage(new StatelessPage()); and that causes the error on refresh. > > > > > > > > > > > > > > maybe the thing to do is to force a bookmarkable url for all > stateless pages even if setResponsePage is used to navigate to them. > > > > > > > > > > > > > > -Igor > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 2/6/06, Johan Compagner <[EMAIL PROTECTED]> wrote: > > > > > > > > bookmarkable pages that don't have callbacks where already > just stateless (don't know exactly what igor did disable now but that did > work fine) > > > > > > > > So that wasn't a problem. > > > > > > > > > > > > > > > > It doesn't have to be only there until it renders.. Because > that was already the case with redirect_to_buffer. > > > > > > > > at first it seems to be ok. Buf if i do a refresh in the > browser i get a page expired message. > > > > > > > > > > > > > > > > What we could do is this: > > > > > > > > > > > > > > > > 1> No call backs (not counting iredirectlistener): Page is > stateless. > > > > > > > > 2> But If a page is redirected store the buffered output and > nothing more as the page state in the session. (sort of the thing we store > now when we do redirect_to_buffer) > > > > > > > > > > > > > > > > Bookmarkable pages always fall into just 1 (if no callbacks) > and never 2 because as far as i know bookmarkable pages are not redirected. > > > > > > > > > > > > > > > > > > > > > > > > johan > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 2/6/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > > > > > > > > > But for the redirect, it has only to be there until it > renders. So > > > > > > > > > that would be an in-between situation. > > > > > > > > > > > > > > > > > > But here is another thing. Stateless pages do never need the > redirect, > > > > > > > > > do they? Certainly not in the case of bookmarkable stateless > pages. > > > > > > > > > Actually now that I think of it, that might be a nice > optimization: > > > > > > > > > instead of just applying the redirect pattern to all pages, > we could > > > > > > > > > rather first find out whether it is actually needed. I can > only think > > > > > > > > > of bookmarkable pages now, but there might be more? > > > > > > > > > > > > > > > > > > Eelco > > > > > > > > > > > > > > > > > > > > > > > > > > > On 2/6/06, Johan Compagner <[EMAIL PROTECTED]> wrote: > > > > > > > > > > what i was planning is that when no callbacks are done AND > no redirect is > > > > > > > > > > done to it it is stateless. > > > > > > > > > > If one of the 2 is done it is just statefull, it has to be > in the > > > > > > > > > > pagemap/session > > > > > > > > > > > > > > > > > > > > johan > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 2/6/06, Eelco Hillenius < [EMAIL PROTECTED]> > wrote: > > > > > > > > > > > > > > > > > > > > > > We can also state that solving the redirect strategies > by using a call > > > > > > > > > > > back mechanism is not the best way to go. It is a very > special case, > > > > > > > > > > > which differs greatly from e.g. link calls and form > posts. Can't we > > > > > > > > > > > make it a more special case, and so save the earlier (no > call backs) > > > > > > > > > > > stateless page idea? > > > > > > > > > > > > > > > > > > > > > > Eelco > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 2/6/06, Johan Compagner <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > When is a page stateless? > > > > > > > > > > > > At first we thought when there are no callbacks (not > urlFor()) calls > > > > > > > > > > > > That is working nice. Except in a redirect strategy > (the redirect to > > > > > > > > > > buffer > > > > > > > > > > > > works the first time but that is more by accident.... > the other redirect > > > > > > > > > > > > fails immediantly) > > > > > > > > > > > > > > > > > > > > > > > > So i currently have no idea how we every could have > true stateless > > > > > > > > > > pages. > > > > > > > > > > > > Because of the redirects and refresh/reload button in > a browser. > > > > > > > > > > > > > > > > > > > > > > > > What we could do in the case a redirect is done. Is > store the pure > > > > > > > > > > output in > > > > > > > > > > > > the session pagestack and not all the > components/models.. so purely the > > > > > > > > > > > > string or something else. > > > > > > > > > > > > > > > > > > > > > > > > johan > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 2/6/06, Jesse Sightler < [EMAIL PROTECTED]> > wrote: > > > > > > > > > > > > > Just IMO, but I'd rather see 1.2 delayed than to see > this feature > > > > > > > > > > dropped > > > > > > > > > > > > completely. I think true stateless pages are one of > the biggest > > > > > > > > > > > > advancements in 1.2. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 2/5/06, Igor Vaynberg < [EMAIL PROTECTED]> > wrote: > > > > > > > > > > > > > > unless we can make it work properly in the 1.2 > time frame im +1 for > > > > > > > > > > > > removing it completely. > > > > > > > > > > > > > > > > > > > > > > > > > > > > -Igor > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 2/5/06, Johan Compagner < [EMAIL PROTECTED]> > wrote: > > > > > > > > > > > > > > > i already mentioned this (the error page does go > to page expired > > > > > > > > > > page > > > > > > > > > > > > when you refresh it) > > > > > > > > > > > > > > > This is just a problem. If we redirect to a page > then the page can > > > > > > > > > > > > also not be stateless.. I have currently know idea how > to fix that. > > > > > > > > > > > > > > > And this means that just about all pages must be > in the pagemap > > > > > > > > > > (so > > > > > > > > > > > > they are seen statefull) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Or we have to see if we can "recreate" the page > when it is > > > > > > > > > > requested. > > > > > > > > > > > > So we don't store the full page but just the data that > can construct it > > > > > > > > > > > > again.. > > > > > > > > > > > > > > > But that is not that easy. Just think of the > exception page. We > > > > > > > > > > have > > > > > > > > > > > > to keep a reference to the exception because that is > what is needed to > > > > > > > > > > > > recreate it again. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > johan > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 1/29/06, Igor Vaynberg < > [EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > we have a problem in our stateless page > implementation. we > > > > > > > > > > assume > > > > > > > > > > > > the page is stateless if a urlfor is never called on > it and thus there > > > > > > > > > > are > > > > > > > > > > > > no links leading back to it. this is very crafty and > works great. what > > > > > > > > > > we > > > > > > > > > > > > did not think about is how the page is accessed, ie > the url of the page. > > > > > > > > > > it > > > > > > > > > > > > is possible to get access to a stateless page under a > ?path=x url. if > > > > > > > > > > you > > > > > > > > > > > > hit the refresh button you will get a page expired > error because the url > > > > > > > > > > is > > > > > > > > > > > > pointing to a pagemap entry that was never put in to > the pagemap since > > > > > > > > > > the > > > > > > > > > > > > page is stateless. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > i have currently disabled the support for > stateless pages. see > > > > > > > > > > > > PageMap.put(Page). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > see bug 1417826 for instructions on how to > reproduce the error. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -Igor > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > > > > > > > > > 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://sel.as-us.falkag.net/sel?cmdlnk&kid3432&bid#0486&dat1642 > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > Wicket-develop mailing list > > > > > > > > > > > Wicket-develop@lists.sourceforge.net > > > > > > > > > > > > > > > > > > > > > > https://lists.sourceforge.net/lists/listinfo/wicket-develop > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > > > > > > > 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://sel.as-us.falkag.net/sel?cmdlnk&kid3432&bid#0486&dat1642 > > > > > > > > > > _______________________________________________ > > > > > > > > > Wicket-develop mailing list > > > > > > > > > Wicket-develop@lists.sourceforge.net > > > > > > > > > > https://lists.sourceforge.net/lists/listinfo/wicket-develop > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------- 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://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 _______________________________________________ Wicket-develop mailing list Wicket-develop@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-develop
