Details
-
New Feature
-
Status: Closed
-
Major
-
Resolution: Incomplete
-
7.0.0-M1
-
None
-
None
Description
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/
Attachments
Issue Links
- is related to
-
-
- Resolved
-
- relates to
-
WICKET-5297 Animate ajax DOM manipulation smoothly
-
- Open
-
- links to
