[
https://issues.apache.org/jira/browse/WICKET-5290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hendy Irawan updated WICKET-5290:
---------------------------------
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/
was:
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.
History API libraries include:
1. http://backbonejs.org/#Router
2. https://github.com/browserstate/history.js/
> 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
> Reporter: Hendy Irawan
>
> 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
