yes that almost worked in the code. Except that i tried to check for redirectlistener so that that didn't make the page statefullBut this can't be done (i think that is the conclusion now)So the current stateless implementation does work, but it only really works for bookmarkable urls (pages) with
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
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
No the buffer is just the render result. That has nothing to do with
the statefulness of the page.
Eelco
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
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
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.
-IgorOn 2/7/06, Johan Compagner [EMAIL PROTECTED] wrote:
just the buffer is
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
On 2/7/06, Eelco Hillenius [EMAIL PROTECTED] wrote:
I don't agree about those pages not being stateless. They are notstateless in that the actual state of these *pages* - not theirbuffered renderings - is not relevant. There is no component statethat we have to keep to interact with the user, the
the entire point of having a page stateless is that it stores nothing in
session. if we are storing the buffer it eliminates the point.
Storing the buffer in the session has nothing to do with pages being
stateless. I agree the net-result is the same, but it doesn't have to
be like that.
but
On 2/7/06, Eelco Hillenius [EMAIL PROTECTED] wrote:
but we do need to apply it to get. the point of redirect after post pattern is to present the user only with read-only urls. that means refreshing the page does not cause any action to be performed only data read from the db or
whatever. so we
i think what we should do is just say: hey, you accessed this page through a
bookmarkable url, it doesnt have any self-referencing urls - so its
stateless.
Exactly :)
Eelco
---
This SF.net email is sponsored by: Splunk Inc. Do you grep
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
I think that maybe stateless page should be always accessed by
bookmarkable url. The only difference between stateless page and regular
(bookmarkable) page would be that stateless page will not be put in the
pagemap.
But I don't know about setResponsePage. Maybe if
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?
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/sessionjohan
On 2/6/06, Eelco Hillenius [EMAIL PROTECTED] wrote:
We can also state that solving the redirect strategies by
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
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
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
the problem is that that would be hard.A page can be stateless because of no call backs or what everBut it could be constructed with data that you only have on construction timeFor example the Exception page of wicket.
That is a stateless page (no call backs) but it is redirected to, so after a
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
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
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
Now that we know how to test it, would it make sense to add junit test
to the examples or core?
Juergen
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
23 matches
Mail list logo
