On Sun, Aug 4, 2013 at 1:16 AM, Martin Grigorov <mgrigo...@apache.org>wrote:
> 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). > im not sure this will be a problem, just like it isnt a problem when users create two non-ajax requests to the same page. page id is 5 request 1 starts ?wicket-page-id=5 request 2 starts ?wicket-page-id=5 request 1 hits server. pulls page id 5, tweaks it, sends page id 6 back to client request 1 hits server. pulls page id 5, tweaks it, sends page id 7 back to client so both requests work against the same page instance but return different page ids. -igor > > > > > > 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. > > > >> > > > > > > > > > > > > > >
