That's what I said. But of course you can intercept the back-button inAJAX and I just did not know wheter this is a requirement in Wicket. If
it is not in Wicket than well - just makes everything easier.don't know exactly if you catch the back button to do a request to the server to display
Ofcourse this is all doable but what is the real gain? If you do ajax
on the clientside and the
chance is pretty great that it gets hit then don't do clientside for
that page.
Or we could use the SecondLevelCacheSessionStore we now have in our
branch then
we also have unlimited backbutton
as always igor can say it so much better then i can :)But ajax and clientside state really isn't the best combination to have.Because for every request the page state must be sent over and sent back.johan
On 4/30/06, Igor Vaynberg [EMAIL PROTECTED] wrote:
On 4/29/06, Matej Knopp
[EMAIL PROTECTED]
Yeah there's just no perfect world as long as browsers work the way
they work. The big, really big advantage of client state saving is
that there is no limit to history. You can work with internal links
everywhere without ever having to worry they'll get stale. I found
this an ugly limitation of
Eelco Hillenius wrote:
Yeah there's just no perfect world as long as browsers work the way
they work. The big, really big advantage of client state saving is
that there is no limit to history. You can work with internal links
everywhere without ever having to worry they'll get stale. I found
make youre own HttpSessionStore imp and PageEvictionStrategy.Hold a few page/page versions in mem. dump old pages to the database.And get them again only when requested. Delete everything when the session itself is invalidated...
Unlimitted back button..johanOn 4/30/06, Eelco Hillenius [EMAIL
For instance, if you have a tab bar, where the tabs consist of
internal links. Say one of these panels diplays a pageable list. When
the user navigates this list beyond the number of page versions, a
click on a tab will give a page expired exception, as those tabs
really point to a link in
I guess I'm bit slower today :) as I have problem understanding this.
The links are regular wicket 'Link's?
(e.g. new Link() { onClick() { tab.switchPage(X); } }?
I just don't understand. Clicking on navigator increases page versions.
Why are the links pointing to older page version?
-Matej
Yeah, that's an alternative option - which I actually proposed in this
thread yesterday - but the disadvantage is that you need to know quite
a bit about Wicket's internals that way.
It would be great to have something smarter for things like this. I
guess it's kind of the same thing Martijn
At the moment you e.g. click on links of the pageable list component,
you'll be increasing versions - unless that pageable list is
unversioned - and your tab links will thus point to older versions.
Eelco
On 4/30/06, Matej Knopp [EMAIL PROTECTED] wrote:
I guess I'm bit slower today :) as I
Ok, I got just IM-ed by Johan. I think *I* don't have my day. I'm
totally wrong here, as the whole page gets rendered everytime, and the
history is thus in sync.
Forget all the answers I gave on this thread. Duh.
Eelco
On 4/30/06, Eelco Hillenius [EMAIL PROTECTED] wrote:
At the moment you
No problem, everyone can have a bad day :)
-Matej
Eelco Hillenius wrote:
Ok, I got just IM-ed by Johan. I think *I* don't have my day. I'm
totally wrong here, as the whole page gets rendered everytime, and the
history is thus in sync.
Forget all the answers I gave on this thread. Duh.
Eelco
Matej Knopp schrieb:
Johan Compagner wrote:
this is pretyt much all in place.
I don't believe in a cookie and or url state what is that? storing a
page in an url?
We have a branch where we have a first draft of ClientSide Page
saving (in an javascript variable that is then set in a hidden
but that is not client state.That is serverside state. the unique id you are talking about is the page id pointing to a page instance.So what is the point of having a client side state if you work that way. as far as i can see zero.
On 4/30/06, Christian Essl [EMAIL PROTECTED] wrote:
Matej
Johan Compagner schrieb:
Ajax don't have back button problems because the history doesn't
change in the browser
(at least as long as the client doesn't do that through javascript)
That's what I said. But of course you can intercept the back-button in
AJAX and I just did not know wheter this is
i saw this thread on wicket-user today and wanted to comment on client-side state.i think the right thing for wicket is to support a generalized interface for storing session state. it could be that the existing ISessionStore interface
or some modification of it is sufficient. but whatever the
this is pretyt much all in place.I don't believe in a cookie and or url state what is that? storing a page in an url?We have a branch where we have a first draft of ClientSide Page saving (in an _javascript_ variable that is then set in a hidden field of all the forms)
Johan Compagner wrote:
this is pretyt much all in place.
I don't believe in a cookie and or url state what is that? storing a
page in an url?
We have a branch where we have a first draft of ClientSide Page saving
(in an javascript variable that is then set in a hidden field of all the
On 4/29/06, Matej Knopp [EMAIL PROTECTED] wrote:
Johan Compagner wrote: this is pretyt much all in place. I don't believe in a cookie and or url state what is that? storing a page in an url? We have a branch where we have a first draft of ClientSide Page saving
(in an _javascript_ variable that
19 matches
Mail list logo
