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
