all urls in the browser are just exact. Maybe we can give an option. When an normal request come in ignore the version info. always return the latest.
johan On 2/8/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
Can't we come up with something smart like recording the last non-ajax request so that when a request for exactly that url comes in after a couple version changing ajax request we now that we have to discard version info but just serve the latest? Eelco On 2/8/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > if the problem is knowing the version ( [20] part of the url ) on the server > side, can we not keep track of it in a js var, and then modify our > wicket.ajax.request javascript to append it to every url for every ajax > request? > > this should work for ajax->ajax but wont work for ajax->regular, but at > least its a start > > -igor > > > On 2/8/07, Matej Knopp <[EMAIL PROTECTED]> wrote: > > > > Igor Vaynberg wrote: > > > On 2/8/07, Jan Vermeulen <[EMAIL PROTECTED]> wrote: > > >> > > >> > > >> >but what is a previous page? you said you only have a single page? > > >> > > >> Yes, we have one 'physical' Wicket page. But of course, our application > > >> contains various 'conceptual' pages (physically panels), i.e. > > components > > >> that make up the body of that single page, and that we go replacing as > > >> the > > >> user navigates. With previous, I mean the same Wicket page, but a > > >> previous > > >> panel. > > > > > > > > > i see > > > > > >> wicket's ajax requests should never generate a new version, because > > ajax > > >> requests do > > >> >not change the page url and thus there is no back-button history - > > >> and so > > >> a > > >> >version is not needed. > > >> > > >> That's why I started this thread in the first place: we are using ajax > > >> requests to replace these 'conceptual pages' (panels), and would have > > >> liked > > >> a history of that. But for what I read around here, this would be a > > hell > > >> of > > >> a job. I suppose we should re-render the whole page each time. > > > > > > > > > hmm....yes it would be quiet difficult. the thing is that wicket is not > > a > > > 100% ajax driven framework so we have some limitations when compared to > > the > > > likes of backbase and gwt when it comes to things such as this. you see > > our > > > versioning is designed to keep state in sync with the backbutton of the > > > browser which is of course non-existant when it comes to ajax. > > > > > > im not really sure how gwt emulates the back button, maybe we can look > > at > > > that and use the same approach. keep in mind that most of us are not > > > javascript gurus :) this would defintely be the area where we could use > > the > > > help/input/ideas/patches from our users :) it should be doable, but > > > difficult :) > > I hate to disappoint you, but i really doubt it's doable in wicket. GWT > > and backbase work completely different than wicket. It's possible to > > support ajax and backbutton for a framework that is completely > > ajax-driven. But Wicket is not the case. > > > > Biggest problem is updating the url. Consider the situation when you do > > 5 ajax requests on a page (incrementing page version by 5). Then you > > reload the page (ctrl+r) and got those 5 versions reverted. That's > > because it's not possible to update the url in javascript withou > > reloading the page. Changing url hash doesn't help, as it's not > > submitted to server. > > > > I've been thinking about supporting ajax and backbutton in wicket, but > > this thing is a real showstopper. > > > > -Matej > > > > > > > > >> B.t.w.: thanks for the great support, the quick response from the core > > >> developers, the open mind to new ideas, etc. We made the right choice > > in > > >> going to Wicket ! > > > > > > > > > glad to hear it! > > > > > > -igor > > > > > > > >
