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 somethi
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
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_)Also i don't like this to much. Because if you do use ajax a little bit then the page is in the session anyway.
And doing the right thing on the
Johan Compagner schrieb:
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.
Hi Johan,
Thanks for your
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 Kn
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
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 e
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 h
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 pro
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
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 'histor
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 PROT
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
this
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 k
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 PROTECTE
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
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
forms)
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)
https://svn.sourceforge.net/s
18 matches
Mail list logo
