[
https://issues.apache.org/jira/browse/WICKET-5290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrea Del Bene reassigned WICKET-5290:
---------------------------------------
Assignee: Andrea Del Bene
> History API support for navigable AJAX pages/components
> -------------------------------------------------------
>
> Key: WICKET-5290
> URL: https://issues.apache.org/jira/browse/WICKET-5290
> Project: Wicket
> Issue Type: New Feature
> Components: wicket
> Affects Versions: 7.0.0-M1
> Reporter: Hendy Irawan
> Assignee: Andrea Del Bene
>
> I wonder if Wicket 6/7 has or planned for good history API support, i.e.
> navigable ajax updates a la Twitter/Facebook?
> If not then I'd like to propose... It'd make Wicket not only very relevant
> but a breakthrough in a *post*-HTML5 world.
> Originally posted at
> https://issues.apache.org/jira/browse/WICKET-3813?focusedCommentId=13720564&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13720564
> [~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 UI does it.
> **Use Cases**
> 1. **Page parameters** (usually for stateless pages). Most probably very
> common use case, why make a page stateful just to save a few variables? Just
> define a few page params and let LoadableDetachableModel load the rest.
> Instead of storing the page in the session, store the page state in the URL
> and let history API manage that "state".
> 2. **BreadCrumb(Panel) components**. Navigable components, but still inside a
> single page
> 3. **Inter-page navigation**. Page navigation but only target several
> components. Perhaps via whitelisting or blacklisting or a combination of
> both. This seems most challenging compared to the two cases above.
> History API libraries include:
> 1. http://backbonejs.org/#Router
> 2. https://github.com/browserstate/history.js/
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
