On Sat, Aug 3, 2013 at 5:23 PM, Igor Vaynberg <igor.vaynb...@gmail.com>wrote:
> * we need to have two different disk stores - one for ajax versions and one > for non-ajax. this is to ensure that the original rendered page instance is > not evicted if its render is followed by a lot of ajax activity. if it is > evicted then any non-ajax callbacks will break. we already have wicket-ajax > header/url var to distinguish the two kinds of requests. > Let me explain some details for the rest who didn't need to read the data store code recently. When a non-ajax request modifies the component tree or a model then the page is marked as touched and as dirty. "Touched" means that it will be stored in the data store at the end of the request cycle. "Dirty" means that a new pageId is assigned. The pageId is the number you see in the url. When an ajax request does the same the page is marked as touched only. Since the composite key to read a page from the data store is "sessionId+pageId" the non-ajax request adds a new entry in the store, while the ajax request overrides the previous entry with the same pageId. So I agree, we will need to modify the current code to use either two stores or one store with key "sessionId+pageId+ajaxId". At the moment I also think that second store would be simpler solution. > > * for ajax links we would need to ignore the version encoded in the > callback params and pass it instead in an additional url param from client > to server and set it in a javascript block so it makes it from server to > client. > I can see how this won't work in case of two simultaneous Ajax requests on different Ajax channels. The second request will wait on PageAccessSynchronizer and won't know about the new Ajax version/id. One way to solve this is to use optimistic update of Wicket.Ajax.pageId (the Ajax id). > > once these two things are in place we can figure out which history library > to work in. the ajax response will need a target.setHistoryPoint(true) or > something like that so we know to enable history for specific > requests/responses. > > ive done some work on shuttling the page id in back and forth in ajax > requests: https://gist.github.com/ivaynberg/6146817 Great! > > > -igor > A friend of mine recommended me Google Closure library<http://docs.closure-library.googlecode.com/git/class_goog_History.html> for history management. It is used by many Google apps, but I haven't seen a new third party blog/article about it since very long time. > > > On Thu, Aug 1, 2013 at 1:32 AM, Martin Grigorov <mgrigo...@apache.org > >wrote: > > > Hi, > > > > Assuming that there is a good JS library for managing the history events, > > what should Wicket do ? > > I guess the best reliable solution is to store the pages as we do now for > > non-Ajax requests. > > > > The problem is that this way the disk store will be filled up much > faster. > > The page will be stored only if it is dirty, i.e. if there are changes in > > its tree. > > > > > > On Fri, Jul 26, 2013 at 1:00 PM, Martin Grigorov <mgrigo...@apache.org > > >wrote: > > > > > Hi, > > > > > > > > > On Fri, Jul 26, 2013 at 12:48 PM, Hendy Irawan <he...@soluvas.com> > > wrote: > > > > > >> I wonder if Wicket 6/7 has or planned for good history API support, > i.e. > > >> navigable ajax updates a la Twitter/Facebook? > > >> > > > > > > It will be very useful if we extract use cases for this functionality. > > > > > > > > >> > > >> If not then I'd like to propose... It'd make Wicket not only very > > relevant > > >> but a breakthrough in a *post*-HTML5 world. > > >> > > >> [~mgrigorov] responded: > > >> > > >> > Do you know of a good JS History library ? > > >> > All I have tried have issues for different browsers. > > >> > > >> What I ever used is Backbone. Which is a great all around library. > > >> > > >> Snippet from http://backbonejs.org/#Router : > > >> > > >> <blockquote> > > >> Web applications often provide linkable, bookmarkable, shareable URLs > > for > > >> important locations in the app. Until recently, hash fragments (#page) > > >> were > > >> used to provide these permalinks, but with the arrival of the History > > API, > > >> it's now possible to use standard URLs (/page). Backbone.Router > provides > > >> methods for routing client-side pages, and connecting them to actions > > and > > >> events. For browsers which don't yet support the History API, the > Router > > >> handles graceful fallback and transparent translation to the fragment > > >> version of the URL. > > >> </blockquote> > > >> > > >> Breadcrumb components would benefit greatly from History API support > > (and > > >> is > > >> probably its main use case). > > >> > > >> Although any parameterizable page will benefit from this. For example > > >> we're > > >> developing an analytics app so the parameters include date range, > > >> precision, > > >> and selected sections. Those can be encoded in URI. Although while > > >> selecting > > >> these things we immediately perform AJAX updates, with bookmarkable > URI > > >> it'd > > >> great. So the page stays "stateless" instead of stateful. Just like > how > > >> Google Analytics does it. > > >> > > >> History API libraries include: > > >> > > >> 1. http://backbonejs.org/#Router > > >> 2. https://github.com/browserstate/history.js/ > > > > > > > > > The second one is one of those which I have tried and didn't like. It > > > behaved differently than native History API. > > > > > > http://tkyk.github.io/jquery-history-plugin/ - this is the one we use > in > > > our app at the moment but its maintainer stopped supporting it. > > > > > > > > >> > > >> > > >> I also created a ticket at > > >> https://issues.apache.org/jira/browse/WICKET-5290 > > > > > > > > > I think there is a ticket about this already. > > > > > > > > >> > > >> > > >> Hendy > > >> > > >> > > >> > > >> -- > > >> View this message in context: > > >> > > > http://apache-wicket.1842946.n4.nabble.com/Wicket7-History-API-support-for-navigable-AJAX-pages-components-tp4660502.html > > >> Sent from the Forum for Wicket Core developers mailing list archive at > > >> Nabble.com. > > >> > > > > > > > > >
