There is in fact a solution to this :) I've only added support for it into AjaxForm, but there are two links, backLink & forwardLink that enable you to control what happens when the user hits their back / forward button on your form.
This isn't anything I've done, just yet another incredibly cool feature provided by dojo. It's discussed in this article, http://dojotoolkit.org/docs/intro_to_dojo_io.html. You can also see a demonstration of it in the tacos demo by hitting the "Form Effects" page. For more general purposes dojo is currently working on a very cool client-side persistant storage API that provides a much larger amount of support in this area than even the back/forward semantics. It's fairly clever in that it eliminates the need to do a bunch of url re-writing to carry state around on the client, but you really do have to be ok with forcing your users to have javascript enabled...Really though, who doesn't have javascript on their browsers these days? BTW, The autocompleter is probably the last remaining non-dojo item being used, but it does use it to actually send the request to the server so adding in back/forward semantics wouldn't be very hard if desired. On 11/22/05, Norbert Sándor <[EMAIL PROTECTED]> wrote: > Probably client persistence would work in this case. (Which stores data in > all URLs ;) ) > I hope someone can give you a hint for session persistency as well... > > > Another problem is the BACK button. How can I handle it correctly using > session persistency? > I was thinking about creating a versioned session persistency strategy > (anyone created one yet? :) It would write a version number to every URL, > and the data is stored in the session for each version. When BACK is clicked > then the actual version is extracted from the request URL, so we know which > version should be used from the session. > I would implement it if noone has done yet but first I want to know if this > would work in case of tacos AJAX components. Tacos developers, please? :) > > What I did until this: I stored the currently edited object in a hidden > field. So when the user pressed BACK (f*ck :) then I extracted the edited > object from the posted request. The problem is that in this case > tacos:autocompleter (and others) fails to work correctly because it does not > post the entire form (so the edited object would be null when serving the > ajax request). > > What is the preferred data storing mechanism which works for ajax, back > button, tabbed browsing, etc.? Maybe there is no such universal solution... > > BR, > Norbi > > ----- Original Message ----- > From: <[EMAIL PROTECTED]> > To: <[email protected]> > Sent: Tuesday, November 22, 2005 1:59 AM > Subject: Persistence when user 'tabs' throug my app ? > > > > Hi ! > > > > I just started to learn the Tapestry-Framework and to check if it will > > meet my requirements. > > > > After generating some pages and components I decided to implement a > > 'simple' menu-system with linked menu-components for site-navigation. > > > > But I ran in some serious trouble finding a place to store the menu-state. > > Every menu-component has to know the active item of the menu-group it > > belongs to. > > > > When clicking an item on the menu a listener ist fired getting the now > > active item as a parameter via DirectLink and informing all menus in the > > group that the active item has changed. > > > > But: where to store this information ? Once a user clicked another link on > > the page, the 'DirectLink-url' with the parameter is gone :( > > > > First try was the Visit-object. OK, works well .. for just one session > > from > > a computer. Having cookies enabled and opening a new browser-tab in > > firefox > > will produce some amazing results when using both tabs to navigate and > > clicking the 'refresh'-button of the browser. Tab 'A' uses the menu-state > > of tab 'B' :( > > > > The application-state is 'mixed' because of the duplicate session-id. > > > > Ok, so I disabled cookies - and running in the same problem very fast: > > ctrl-clicking a link in the application opens a new tab in firefox (a > > real-world-problem :) ) ... with the same jsessionID passed by the > > DirectLink-component :( > > > > Hmmm ... I am to new to Tapestry to find a solution for this :( > > > > In an old-fashioned application I would encode the state permanently into > > the url as a query-parameter. So every single page can get the menu-state > > out of the url - and my problem would be solved. > > > > But I am sure, there are better ways to do so in Tapestry (3.0.3) ? > > > > Using a <property-specification> in the form/page doesn't work, too - this > > property is stored in the HttpSession also :( > > > > Would be great to get some feedback on this 'problem'. Maybe the solution > > is very easy - but I can't find any information about it .. > > > > Thank you in advance ! > > > > Bye, > > Gerald > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
