-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.
johanOn 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.
-IgorOn 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.
johanOn 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?
-IgorOn 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.
johanOn 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.
-IgorOn 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.
johanOn 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
> > [email protected]
> >
> 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
