[Wicket7] History API support for navigable AJAX pages/components?

[Hendy Irawan <he...@soluvas.com>]

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. 

[~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/ 

I also created a ticket at https://issues.apache.org/jira/browse/WICKET-5290

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.

Re: [Wicket7] History API support for navigable AJAX pages/components?

[Hendy Irawan <he...@soluvas.com>]

Hi,

I don't like URL fragments either.
For unsupported browsers, I would prefer downgrading to normal stateful
AJAX.

Hendy

Hendy Irawan - on Twitter <http://twitter.com/hendybippo> - on
LinkedIn<http://id.linkedin.com/in/hendyirawan>
Web Developer | Bippo Indonesia <http://www.bippo.co.id/> | Akselerator
Bisnis | Bandung


On Mon, Sep 23, 2013 at 7:19 PM, Martin Grigorov-4 [via Apache Wicket] <
ml-node+s1842946n4661445h93@n4.nabble.com> wrote:

> Hi,
>
>
> On Mon, Sep 23, 2013 at 1:59 PM, Hendy Irawan <[hidden email]<http://user/SendEmail.jtp?type=node&node=4661445&i=0>>
> wrote:
>
> > Hi,
> >
> > The way I see it now this will enable a lot of our frontend pages to be
> > stateless.
> >
> > Currently http://www.tuneeca.com powered by Wicket 6.8.0 has mostly
> > stateful
> > frontend pages (except for HomePage, which we made the effort to be
> > stateless to reduce pagestore/session usage).
> >
> > Most of the "state" are used for paging, sorting, and filter, which we
> > happen to use Wicket's AJAX built-in support heavily (thanks Wicket!!
> :-) )
> > but of course this makes the pages has ?id in them.
> >
> > I think it'd be possible to encode all the "state" a page wants in, e.g.
> :
> >
> >
> >
> http://www.tuneeca.com/release/carribean_dream?lowerPrice=50000&upperPrice=200000&sort=name&page=2
> >
> > or perhaps:
> >
> >
> >
> http://www.tuneeca.com/release/carribean_dream/lowerPrice/50000/upperPrice/200000/sort/name/page/2
>
>
> Both of these urls won't work in IE 8/9/10 because these versions of IE do
> not support HTML5 History API.
> To support history you will need to use Url fragments, i.e. something
> like:
>
>
> http://www.tuneeca.com/release/carribean_dream?#lowerPrice/50000/upperPrice/200000/sort/name/page/2
> or
>
> http://www.tuneeca.com/release/carribean_dream?#lowerPrice=50000&upperPrice=200000&sort=name&page=2
>
>
>
> >
> > With the History API support it'd should be possible to do this, while
> > retaining four (!!) awesome characteristics :
> >
> > 1. AJAX - faster loading due to less bandwidth usage
> > 2. Bookmarkable - the URLs (+ parameters) are immediately bookmarkable
> and
> > consistent.
> >
>
> With the Url fragments this is not quite true.
> The url is bookmarkable but will require some extra JavaScript onload
> logic
> to make an Ajax call to the server after initially loading the page.
> Twitter used to use this approach but it didn't worked well. There are
> blog
> articles about the problems.
>
>
> > 3. Statelessness - faster loading (internally), which results in:
> >
>
> How exactly it will be faster ?
>
>
> > 4. Less session/pagestore usage - faster loading because less I/O, also
> > saves precious heap & disk space :-)
> >
>
> Those are not so precious these days.
> Actually developers' salary is bigger than their cost.
>
>
> >
> > Point 3 & 4 above are only possible with proper stateless links/buttons
> > etc.
> > (which I assume will be one of the improved features of Wicket 7?)
> >
>
> There are no such improvements at the moment.
>
> But there is
> http://central.maven.org/maven2/org/wicketstuff/wicketstuff-stateless/
>
>
> >
> > Of course I haven't yet made a Proof of concept of this... (sorry!) but
> > just
> > thinking about this made me excited. If this works out, Wicket 7's
> > definitely going to be the most awesome web framework of all (not that
> it
> > hasn't, mind you :-)).
> >
> > Hendy
> >
> >
> >
> >
> > --
> > View this message in context:
> >
> http://apache-wicket.1842946.n4.nabble.com/Wicket7-History-API-support-for-navigable-AJAX-pages-components-tp4660502p4661443.html
>
> > Sent from the Forum for Wicket Core developers mailing list archive at
> > Nabble.com.
> >
>
>
> ------------------------------
>  If you reply to this email, your message will be added to the discussion
> below:
>
> http://apache-wicket.1842946.n4.nabble.com/Wicket7-History-API-support-for-navigable-AJAX-pages-components-tp4660502p4661445.html
>  To unsubscribe from [Wicket7] History API support for navigable AJAX
> pages/components?, click here<http://apache-wicket.1842946.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4660502&code=aGVuZHlAc29sdXZhcy5jb218NDY2MDUwMnwxNTI0Njc4NzUy>
> .
> NAML<http://apache-wicket.1842946.n4.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>




--
View this message in context: http://apache-wicket.1842946.n4.nabble.com/Wicket7-History-API-support-for-navigable-AJAX-pages-components-tp4660502p4661451.html
Sent from the Forum for Wicket Core developers mailing list archive at Nabble.com.

Re: [Wicket7] History API support for navigable AJAX pages/components?

[Hendy Irawan <he...@soluvas.com>]

Thanks!

BTW... To experience the awesomeness of proper History API behavior +
animation, check this out:

http://www.spaceheadconcepts.com/alive-wp

(be sure to also test the back/forward button behavior!) :)

Hendy


Hendy Irawan - on Twitter <http://twitter.com/hendybippo> - on
LinkedIn<http://id.linkedin.com/in/hendyirawan>
Web Developer | Bippo Indonesia <http://www.bippo.co.id/> | Akselerator
Bisnis | Bandung


On Thu, Sep 26, 2013 at 9:06 PM, Martin Grigorov-4 [via Apache Wicket] <
ml-node+s1842946n4661534h52@n4.nabble.com> wrote:

> On Thu, Sep 26, 2013 at 10:58 PM, Hendy Irawan <[hidden email]<http://user/SendEmail.jtp?type=node&node=4661534&i=0>>
> wrote:
>
> > Good news!
> >
> > I've created a proof-of-concept project using Wicket 6.10 :
> >
> > https://github.com/ceefour/wicket-historyapi
> >
> > There are 3 approaches:
> > 1. redirect
> > 2. stateless
> > 3. history API
> >
> > (Actually there should be a stateful approach too.)
> >
> > The History API is using history.js (don't worry, HTML4 support is
> disabled
> > i.e. no hashbangs).
> >
> > What I'd like to have is a hybrid approach that combines approach #1
> > (redirect, for non-supporting browsers e.g. IE10 & Googlebot) + #3
> (history
> > API, for supporting browsers). Not sure how to do this yet....
> >
> > As it is now, all these approaches require workarounds and non-standard
> > Wicket components, and especially the "stateless" approach aren't
> working
> > in certain situations.
> >
> > It'd be great if the combined approach would work out-of-the-box with
> > Wicket 7.
> >
> > And one more thing would be transitions and animations. This is not
> > exclusive to history API/stateless support but some support in core
> would
> > be very appreciated. e.g. an API such as this would be wonderful:
> >
> > target.add( myComponent, Animation.fadeOut(250), Animation.fadeIn(400)
> );
> >
>
> Before you create a ticket:
> https://issues.apache.org/jira/browse/WICKET-5297
>
>
> >
> > Thank you.
> >
> > Hendy
> >
> >
> > Hendy Irawan - on Twitter <http://twitter.com/hendybippo> - on
> > LinkedIn<http://id.linkedin.com/in/hendyirawan>
> > Web Developer | Bippo Indonesia <http://www.bippo.co.id/> | Akselerator
> > Bisnis | Bandung
> >
> >
> > On Mon, Sep 23, 2013 at 1:58 PM, Hendy Irawan <[hidden email]<http://user/SendEmail.jtp?type=node&node=4661534&i=1>>
> wrote:
> >
> > > Hi,
> > >
> > > I don't like URL fragments either.
> > > For unsupported browsers, I would prefer downgrading to normal
> stateful
> > > AJAX.
> > >
> > > Hendy
> > >
> > > Hendy Irawan - on Twitter <http://twitter.com/hendybippo> - on
> LinkedIn<
> > http://id.linkedin.com/in/hendyirawan>
> > > Web Developer | Bippo Indonesia <http://www.bippo.co.id/> |
> Akselerator
> > > Bisnis | Bandung
> > >
> > >
> > > On Mon, Sep 23, 2013 at 7:19 PM, Martin Grigorov-4 [via Apache Wicket]
> <
> > > [hidden email] <http://user/SendEmail.jtp?type=node&node=4661534&i=2>>
> wrote:
> > >
> > >> Hi,
> > >>
> > >>
> > >> On Mon, Sep 23, 2013 at 1:59 PM, Hendy Irawan <[hidden email]<
> > http://user/SendEmail.jtp?type=node&node=4661445&i=0>>
> > >> wrote:
> > >>
> > >> > Hi,
> > >> >
> > >> > The way I see it now this will enable a lot of our frontend pages
> to
> > be
> > >> > stateless.
> > >> >
> > >> > Currently http://www.tuneeca.com powered by Wicket 6.8.0 has
> mostly
> > >> > stateful
> > >> > frontend pages (except for HomePage, which we made the effort to be
> > >> > stateless to reduce pagestore/session usage).
> > >> >
> > >> > Most of the "state" are used for paging, sorting, and filter, which
> we
> > >> > happen to use Wicket's AJAX built-in support heavily (thanks
> Wicket!!
> > >> :-) )
> > >> > but of course this makes the pages has ?id in them.
> > >> >
> > >> > I think it'd be possible to encode all the "state" a page wants in,
> > >> e.g. :
> > >> >
> > >> >
> > >> >
> > >>
> >
> http://www.tuneeca.com/release/carribean_dream?lowerPrice=50000&upperPrice=200000&sort=name&page=2
> > >> >
> > >> > or perhaps:
> > >> >
> > >> >
> > >> >
> > >>
> >
> http://www.tuneeca.com/release/carribean_dream/lowerPrice/50000/upperPrice/200000/sort/name/page/2
> > >>
> > >>
> > >> Both of these urls won't work in IE 8/9/10 because these versions of
> IE
> > >> do
> > >> not support HTML5 History API.
> > >> To support history you will need to use Url fragments, i.e. something
> > >> like:
> > >>
> > >>
> > >>
> >
> http://www.tuneeca.com/release/carribean_dream?#lowerPrice/50000/upperPrice/200000/sort/name/page/2
> > >> or
> > >>
> > >>
> >
> http://www.tuneeca.com/release/carribean_dream?#lowerPrice=50000&upperPrice=200000&sort=name&page=2
> > >>
> > >>
> > >>
> > >> >
> > >> > With the History API support it'd should be possible to do this,
> while
> > >> > retaining four (!!) awesome characteristics :
> > >> >
> > >> > 1. AJAX - faster loading due to less bandwidth usage
> > >> > 2. Bookmarkable - the URLs (+ parameters) are immediately
> bookmarkable
> > >> and
> > >> > consistent.
> > >> >
> > >>
> > >> With the Url fragments this is not quite true.
> > >> The url is bookmarkable but will require some extra JavaScript onload
> > >> logic
> > >> to make an Ajax call to the server after initially loading the page.
> > >> Twitter used to use this approach but it didn't worked well. There
> are
> > >> blog
> > >> articles about the problems.
> > >>
> > >>
> > >> > 3. Statelessness - faster loading (internally), which results in:
> > >> >
> > >>
> > >> How exactly it will be faster ?
> > >>
> > >>
> > >> > 4. Less session/pagestore usage - faster loading because less I/O,
> > also
> > >> > saves precious heap & disk space :-)
> > >> >
> > >>
> > >> Those are not so precious these days.
> > >> Actually developers' salary is bigger than their cost.
> > >>
> > >>
> > >> >
> > >> > Point 3 & 4 above are only possible with proper stateless
> > links/buttons
> > >> > etc.
> > >> > (which I assume will be one of the improved features of Wicket 7?)
> > >> >
> > >>
> > >> There are no such improvements at the moment.
> > >>
> > >> But there is
> > >>
> http://central.maven.org/maven2/org/wicketstuff/wicketstuff-stateless/
> > >>
> > >>
> > >> >
> > >> > Of course I haven't yet made a Proof of concept of this... (sorry!)
> > but
> > >> > just
> > >> > thinking about this made me excited. If this works out, Wicket 7's
> > >> > definitely going to be the most awesome web framework of all (not
> that
> > >> it
> > >> > hasn't, mind you :-)).
> > >> >
> > >> > Hendy
> > >> >
> > >> >
> > >> >
> > >> >
> > >> > --
> > >> > View this message in context:
> > >> >
> > >>
> >
> http://apache-wicket.1842946.n4.nabble.com/Wicket7-History-API-support-for-navigable-AJAX-pages-components-tp4660502p4661443.html
> > >>
> > >> > Sent from the Forum for Wicket Core developers mailing list archive
> at
> > >> > Nabble.com.
> > >> >
> > >>
> > >>
> > >> ------------------------------
> > >>  If you reply to this email, your message will be added to the
> > >> discussion below:
> > >>
> > >>
> >
> http://apache-wicket.1842946.n4.nabble.com/Wicket7-History-API-support-for-navigable-AJAX-pages-components-tp4660502p4661445.html
> > >>  To unsubscribe from [Wicket7] History API support for navigable AJAX
> > >> pages/components?, click here<
> >
> >
> > >> .
> > >> NAML<
> >
> http://apache-wicket.1842946.n4.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml
>
> > >
> > >>
> > >
> > >
> >
> >
> >
> >
> > --
> > View this message in context:
> >
> http://apache-wicket.1842946.n4.nabble.com/Wicket7-History-API-support-for-navigable-AJAX-pages-components-tp4660502p4661532.html
>
> > Sent from the Forum for Wicket Core developers mailing list archive at
> > Nabble.com.
> >
>
>
> ------------------------------
>  If you reply to this email, your message will be added to the discussion
> below:
>
> http://apache-wicket.1842946.n4.nabble.com/Wicket7-History-API-support-for-navigable-AJAX-pages-components-tp4660502p4661534.html
>  To unsubscribe from [Wicket7] History API support for navigable AJAX
> pages/components?, click here<http://apache-wicket.1842946.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4660502&code=aGVuZHlAc29sdXZhcy5jb218NDY2MDUwMnwxNTI0Njc4NzUy>
> .
> NAML<http://apache-wicket.1842946.n4.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>




--
View this message in context: http://apache-wicket.1842946.n4.nabble.com/Wicket7-History-API-support-for-navigable-AJAX-pages-components-tp4660502p4661536.html
Sent from the Forum for Wicket Core developers mailing list archive at Nabble.com.

Re: [Wicket7] History API support for navigable AJAX pages/components?

[Martin Grigorov <mg...@apache.org>]

On Thu, Sep 26, 2013 at 10:58 PM, Hendy Irawan <he...@soluvas.com> wrote:

> Good news!
>
> I've created a proof-of-concept project using Wicket 6.10 :
>
> https://github.com/ceefour/wicket-historyapi
>
> There are 3 approaches:
> 1. redirect
> 2. stateless
> 3. history API
>
> (Actually there should be a stateful approach too.)
>
> The History API is using history.js (don't worry, HTML4 support is disabled
> i.e. no hashbangs).
>
> What I'd like to have is a hybrid approach that combines approach #1
> (redirect, for non-supporting browsers e.g. IE10 & Googlebot) + #3 (history
> API, for supporting browsers). Not sure how to do this yet....
>
> As it is now, all these approaches require workarounds and non-standard
> Wicket components, and especially the "stateless" approach aren't working
> in certain situations.
>
> It'd be great if the combined approach would work out-of-the-box with
> Wicket 7.
>
> And one more thing would be transitions and animations. This is not
> exclusive to history API/stateless support but some support in core would
> be very appreciated. e.g. an API such as this would be wonderful:
>
> target.add( myComponent, Animation.fadeOut(250), Animation.fadeIn(400) );
>

Before you create a ticket:
https://issues.apache.org/jira/browse/WICKET-5297


>
> Thank you.
>
> Hendy
>
>
> Hendy Irawan - on Twitter <http://twitter.com/hendybippo> - on
> LinkedIn<http://id.linkedin.com/in/hendyirawan>
> Web Developer | Bippo Indonesia <http://www.bippo.co.id/> | Akselerator
> Bisnis | Bandung
>
>
> On Mon, Sep 23, 2013 at 1:58 PM, Hendy Irawan <he...@soluvas.com> wrote:
>
> > Hi,
> >
> > I don't like URL fragments either.
> > For unsupported browsers, I would prefer downgrading to normal stateful
> > AJAX.
> >
> > Hendy
> >
> > Hendy Irawan - on Twitter <http://twitter.com/hendybippo> - on LinkedIn<
> http://id.linkedin.com/in/hendyirawan>
> > Web Developer | Bippo Indonesia <http://www.bippo.co.id/> | Akselerator
> > Bisnis | Bandung
> >
> >
> > On Mon, Sep 23, 2013 at 7:19 PM, Martin Grigorov-4 [via Apache Wicket] <
> > ml-node+s1842946n4661445h93@n4.nabble.com> wrote:
> >
> >> Hi,
> >>
> >>
> >> On Mon, Sep 23, 2013 at 1:59 PM, Hendy Irawan <[hidden email]<
> http://user/SendEmail.jtp?type=node&node=4661445&i=0>>
> >> wrote:
> >>
> >> > Hi,
> >> >
> >> > The way I see it now this will enable a lot of our frontend pages to
> be
> >> > stateless.
> >> >
> >> > Currently http://www.tuneeca.com powered by Wicket 6.8.0 has mostly
> >> > stateful
> >> > frontend pages (except for HomePage, which we made the effort to be
> >> > stateless to reduce pagestore/session usage).
> >> >
> >> > Most of the "state" are used for paging, sorting, and filter, which we
> >> > happen to use Wicket's AJAX built-in support heavily (thanks Wicket!!
> >> :-) )
> >> > but of course this makes the pages has ?id in them.
> >> >
> >> > I think it'd be possible to encode all the "state" a page wants in,
> >> e.g. :
> >> >
> >> >
> >> >
> >>
> http://www.tuneeca.com/release/carribean_dream?lowerPrice=50000&upperPrice=200000&sort=name&page=2
> >> >
> >> > or perhaps:
> >> >
> >> >
> >> >
> >>
> http://www.tuneeca.com/release/carribean_dream/lowerPrice/50000/upperPrice/200000/sort/name/page/2
> >>
> >>
> >> Both of these urls won't work in IE 8/9/10 because these versions of IE
> >> do
> >> not support HTML5 History API.
> >> To support history you will need to use Url fragments, i.e. something
> >> like:
> >>
> >>
> >>
> http://www.tuneeca.com/release/carribean_dream?#lowerPrice/50000/upperPrice/200000/sort/name/page/2
> >> or
> >>
> >>
> http://www.tuneeca.com/release/carribean_dream?#lowerPrice=50000&upperPrice=200000&sort=name&page=2
> >>
> >>
> >>
> >> >
> >> > With the History API support it'd should be possible to do this, while
> >> > retaining four (!!) awesome characteristics :
> >> >
> >> > 1. AJAX - faster loading due to less bandwidth usage
> >> > 2. Bookmarkable - the URLs (+ parameters) are immediately bookmarkable
> >> and
> >> > consistent.
> >> >
> >>
> >> With the Url fragments this is not quite true.
> >> The url is bookmarkable but will require some extra JavaScript onload
> >> logic
> >> to make an Ajax call to the server after initially loading the page.
> >> Twitter used to use this approach but it didn't worked well. There are
> >> blog
> >> articles about the problems.
> >>
> >>
> >> > 3. Statelessness - faster loading (internally), which results in:
> >> >
> >>
> >> How exactly it will be faster ?
> >>
> >>
> >> > 4. Less session/pagestore usage - faster loading because less I/O,
> also
> >> > saves precious heap & disk space :-)
> >> >
> >>
> >> Those are not so precious these days.
> >> Actually developers' salary is bigger than their cost.
> >>
> >>
> >> >
> >> > Point 3 & 4 above are only possible with proper stateless
> links/buttons
> >> > etc.
> >> > (which I assume will be one of the improved features of Wicket 7?)
> >> >
> >>
> >> There are no such improvements at the moment.
> >>
> >> But there is
> >> http://central.maven.org/maven2/org/wicketstuff/wicketstuff-stateless/
> >>
> >>
> >> >
> >> > Of course I haven't yet made a Proof of concept of this... (sorry!)
> but
> >> > just
> >> > thinking about this made me excited. If this works out, Wicket 7's
> >> > definitely going to be the most awesome web framework of all (not that
> >> it
> >> > hasn't, mind you :-)).
> >> >
> >> > Hendy
> >> >
> >> >
> >> >
> >> >
> >> > --
> >> > View this message in context:
> >> >
> >>
> http://apache-wicket.1842946.n4.nabble.com/Wicket7-History-API-support-for-navigable-AJAX-pages-components-tp4660502p4661443.html
> >>
> >> > Sent from the Forum for Wicket Core developers mailing list archive at
> >> > Nabble.com.
> >> >
> >>
> >>
> >> ------------------------------
> >>  If you reply to this email, your message will be added to the
> >> discussion below:
> >>
> >>
> http://apache-wicket.1842946.n4.nabble.com/Wicket7-History-API-support-for-navigable-AJAX-pages-components-tp4660502p4661445.html
> >>  To unsubscribe from [Wicket7] History API support for navigable AJAX
> >> pages/components?, click here<
> http://apache-wicket.1842946.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4660502&code=aGVuZHlAc29sdXZhcy5jb218NDY2MDUwMnwxNTI0Njc4NzUy
> >
> >> .
> >> NAML<
> http://apache-wicket.1842946.n4.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml
> >
> >>
> >
> >
>
>
>
>
> --
> View this message in context:
> http://apache-wicket.1842946.n4.nabble.com/Wicket7-History-API-support-for-navigable-AJAX-pages-components-tp4660502p4661532.html
> Sent from the Forum for Wicket Core developers mailing list archive at
> Nabble.com.
>

Re: [Wicket7] History API support for navigable AJAX pages/components?

[Martin Grigorov <mg...@apache.org>]

On Fri, Sep 27, 2013 at 11:12 AM, Hendy Irawan <he...@soluvas.com> wrote:

> On Fri, Sep 27, 2013 at 8:47 AM, Martin Grigorov-4 [via Apache Wicket] <
> ml-node+s1842946n4661552h10@n4.nabble.com> wrote:
>
> > On Thu, Sep 26, 2013 at 10:58 PM, Hendy Irawan <[hidden email]<
> http://user/SendEmail.jtp?type=node&node=4661552&i=0>>
> > wrote:
> >
> > > Good news!
> > >
> > > I've created a proof-of-concept project using Wicket 6.10 :
> > >
> > > https://github.com/ceefour/wicket-historyapi
> > >
> > > There are 3 approaches:
> > > 1. redirect
> > > 2. stateless
> > > 3. history API
> > >
> > > (Actually there should be a stateful approach too.)
> > >
> > > The History API is using history.js (don't worry, HTML4 support is
> > disabled
> > > i.e. no hashbangs).
> > >
> >
> > Actually this worries me. As a framework Wicket should support older
> > browsers.
> > At the moment we support IE8+.
> > I'm not sure when we will be able to drop support for IE 8 and 9.
> >
> >
> How to support older browsers, it's a choice. history.js has support for
> HTML4 via hashbangs.
> Since you said you didn't like it, and neither do I, it doesn't mean that
> "Wicket won't support older browsers",
> it means that the support will be in another form, i.e. not hashbang, but
> can be any of:
> 1. redirect (demoed)
> 2. stateless (demoed)
> 3. stateful (not demoed, but everybody already knows this anyway)
>
>
> >
> > >
> > > What I'd like to have is a hybrid approach that combines approach #1
> > > (redirect, for non-supporting browsers e.g. IE10 & Googlebot) + #3
> > (history
> > >
> >
> > According to http://caniuse.com/#search=history IE10 should support
> > Hisotry
> > API.
> >
>
> Thanks for the rechecking! I was referring when you said "IE 8/9/10 because
> these versions of IE do
> not support HTML5 History API". Now that's a good news that IE 10 actually
> support history ! :)
> One less browser to worry about :)
>
>
> >
> >
> > > API, for supporting browsers). Not sure how to do this yet....
> > >
> > > As it is now, all these approaches require workarounds and non-standard
> > > Wicket components, and especially the "stateless" approach aren't
> > working
> > > in certain situations.
> > >
> >
> > Yes. This is the main reason why Wicket do not provide official support
> > for
> > them, i.e. they are not part of wicket-core.
> >
>
> I'm hoping this can improve for Wicket 7. If not in Wicket 7 Core, then at
> least Core improvements (i.e. "enablers") so that building on top of it
> will feel more natural and less hacky.
>
> One of the foundation blocks to enable this would be Stateless support /
> components:
>
>
> https://cwiki.apache.org/confluence/display/WICKET/Ideas+for+Wicket+7.0#IdeasforWicket7.0-Betterstatelesssupport
>
> wicket-stateless as it stands now is already awesome. Any plans to merge
> this into Wicket 7 core/extensions?
>

There were discussions whether to add wicket-stateless in Apache Wicket and
we decided to not do it.
Search in archives.


>
>
>
> >
> >
> > >
> > > It'd be great if the combined approach would work out-of-the-box with
> > > Wicket 7.
> > >
> > > And one more thing would be transitions and animations. This is not
> > > exclusive to history API/stateless support but some support in core
> > would
> > > be very appreciated. e.g. an API such as this would be wonderful:
> > >
> > > target.add( myComponent, Animation.fadeOut(250), Animation.fadeIn(400)
> > );
> > >
> >
> > See http://wicketinaction.com/2013/02/replace-components-with-animation/
> >  and
> >
> >
> https://github.com/martin-g/blogs/blob/master/wicket6-replace-with-effect/src/main/java/com/mycompany/HomePage.java#L36
> > .
> >
>
> Indeed that's exactly what I used in the demo:
>
> https://github.com/ceefour/wicket-historyapi/blob/4529b29050ffee2becdab70c1ad9e170ef945568/src/main/java/com/hendyirawan/wickethistory/Html5HistoryPage.java
>
> My point was to show that although it can be done in Wicket 6, it's not
> natural and not an integral part of Wicket 6. This is what I hope will be
> improved in Wicket 7.
>
> Hendy
>
>
> > I think it will be better if composition is used instead. For example:
> >
> > Effect hideEffect = new FadeOut(duration);
> > Effect showEffect = new SlideIn(duration);
> > Effects.replace(target, component, hideEffect, showEffect)
> >
> >
> Awesome !
>
> I'm pretty sure I won't complain much about the API.. as long as it's in
> Wicket, then I'm happy ^_^


> Hendy
>
>
>
>
> --
> View this message in context:
> http://apache-wicket.1842946.n4.nabble.com/Wicket7-History-API-support-for-navigable-AJAX-pages-components-tp4660502p4661555.html
> Sent from the Forum for Wicket Core developers mailing list archive at
> Nabble.com.
>

Re: [Wicket7] History API support for navigable AJAX pages/components?

[Hendy Irawan <he...@soluvas.com>]

On Fri, Sep 27, 2013 at 8:47 AM, Martin Grigorov-4 [via Apache Wicket] <
ml-node+s1842946n4661552h10@n4.nabble.com> wrote:

> On Thu, Sep 26, 2013 at 10:58 PM, Hendy Irawan <[hidden email]<http://user/SendEmail.jtp?type=node&node=4661552&i=0>>
> wrote:
>
> > Good news!
> >
> > I've created a proof-of-concept project using Wicket 6.10 :
> >
> > https://github.com/ceefour/wicket-historyapi
> >
> > There are 3 approaches:
> > 1. redirect
> > 2. stateless
> > 3. history API
> >
> > (Actually there should be a stateful approach too.)
> >
> > The History API is using history.js (don't worry, HTML4 support is
> disabled
> > i.e. no hashbangs).
> >
>
> Actually this worries me. As a framework Wicket should support older
> browsers.
> At the moment we support IE8+.
> I'm not sure when we will be able to drop support for IE 8 and 9.
>
>
How to support older browsers, it's a choice. history.js has support for
HTML4 via hashbangs.
Since you said you didn't like it, and neither do I, it doesn't mean that
"Wicket won't support older browsers",
it means that the support will be in another form, i.e. not hashbang, but
can be any of:
1. redirect (demoed)
2. stateless (demoed)
3. stateful (not demoed, but everybody already knows this anyway)


>
> >
> > What I'd like to have is a hybrid approach that combines approach #1
> > (redirect, for non-supporting browsers e.g. IE10 & Googlebot) + #3
> (history
> >
>
> According to http://caniuse.com/#search=history IE10 should support
> Hisotry
> API.
>

Thanks for the rechecking! I was referring when you said "IE 8/9/10 because
these versions of IE do
not support HTML5 History API". Now that's a good news that IE 10 actually
support history ! :)
One less browser to worry about :)


>
>
> > API, for supporting browsers). Not sure how to do this yet....
> >
> > As it is now, all these approaches require workarounds and non-standard
> > Wicket components, and especially the "stateless" approach aren't
> working
> > in certain situations.
> >
>
> Yes. This is the main reason why Wicket do not provide official support
> for
> them, i.e. they are not part of wicket-core.
>

I'm hoping this can improve for Wicket 7. If not in Wicket 7 Core, then at
least Core improvements (i.e. "enablers") so that building on top of it
will feel more natural and less hacky.

One of the foundation blocks to enable this would be Stateless support /
components:

https://cwiki.apache.org/confluence/display/WICKET/Ideas+for+Wicket+7.0#IdeasforWicket7.0-Betterstatelesssupport

wicket-stateless as it stands now is already awesome. Any plans to merge
this into Wicket 7 core/extensions?



>
>
> >
> > It'd be great if the combined approach would work out-of-the-box with
> > Wicket 7.
> >
> > And one more thing would be transitions and animations. This is not
> > exclusive to history API/stateless support but some support in core
> would
> > be very appreciated. e.g. an API such as this would be wonderful:
> >
> > target.add( myComponent, Animation.fadeOut(250), Animation.fadeIn(400)
> );
> >
>
> See http://wicketinaction.com/2013/02/replace-components-with-animation/
>  and
>
> https://github.com/martin-g/blogs/blob/master/wicket6-replace-with-effect/src/main/java/com/mycompany/HomePage.java#L36
> .
>

Indeed that's exactly what I used in the demo:
https://github.com/ceefour/wicket-historyapi/blob/4529b29050ffee2becdab70c1ad9e170ef945568/src/main/java/com/hendyirawan/wickethistory/Html5HistoryPage.java

My point was to show that although it can be done in Wicket 6, it's not
natural and not an integral part of Wicket 6. This is what I hope will be
improved in Wicket 7.

Hendy


> I think it will be better if composition is used instead. For example:
>
> Effect hideEffect = new FadeOut(duration);
> Effect showEffect = new SlideIn(duration);
> Effects.replace(target, component, hideEffect, showEffect)
>
>
Awesome !

I'm pretty sure I won't complain much about the API.. as long as it's in
Wicket, then I'm happy ^_^

Hendy




--
View this message in context: http://apache-wicket.1842946.n4.nabble.com/Wicket7-History-API-support-for-navigable-AJAX-pages-components-tp4660502p4661555.html
Sent from the Forum for Wicket Core developers mailing list archive at Nabble.com.

Re: [Wicket7] History API support for navigable AJAX pages/components?

[Martin Grigorov <mg...@apache.org>]

On Thu, Sep 26, 2013 at 10:58 PM, Hendy Irawan <he...@soluvas.com> wrote:

> Good news!
>
> I've created a proof-of-concept project using Wicket 6.10 :
>
> https://github.com/ceefour/wicket-historyapi
>
> There are 3 approaches:
> 1. redirect
> 2. stateless
> 3. history API
>
> (Actually there should be a stateful approach too.)
>
> The History API is using history.js (don't worry, HTML4 support is disabled
> i.e. no hashbangs).
>

Actually this worries me. As a framework Wicket should support older
browsers.
At the moment we support IE8+.
I'm not sure when we will be able to drop support for IE 8 and 9.


>
> What I'd like to have is a hybrid approach that combines approach #1
> (redirect, for non-supporting browsers e.g. IE10 & Googlebot) + #3 (history
>

According to http://caniuse.com/#search=history IE10 should support Hisotry
API.


> API, for supporting browsers). Not sure how to do this yet....
>
> As it is now, all these approaches require workarounds and non-standard
> Wicket components, and especially the "stateless" approach aren't working
> in certain situations.
>

Yes. This is the main reason why Wicket do not provide official support for
them, i.e. they are not part of wicket-core.


>
> It'd be great if the combined approach would work out-of-the-box with
> Wicket 7.
>
> And one more thing would be transitions and animations. This is not
> exclusive to history API/stateless support but some support in core would
> be very appreciated. e.g. an API such as this would be wonderful:
>
> target.add( myComponent, Animation.fadeOut(250), Animation.fadeIn(400) );
>

See http://wicketinaction.com/2013/02/replace-components-with-animation/
 and
https://github.com/martin-g/blogs/blob/master/wicket6-replace-with-effect/src/main/java/com/mycompany/HomePage.java#L36
.
I think it will be better if composition is used instead. For example:

Effect hideEffect = new FadeOut(duration);
Effect showEffect = new SlideIn(duration);
Effects.replace(target, component, hideEffect, showEffect)


>
> Thank you.
>
> Hendy
>
>
> Hendy Irawan - on Twitter <http://twitter.com/hendybippo> - on
> LinkedIn<http://id.linkedin.com/in/hendyirawan>
> Web Developer | Bippo Indonesia <http://www.bippo.co.id/> | Akselerator
> Bisnis | Bandung
>
>
> On Mon, Sep 23, 2013 at 1:58 PM, Hendy Irawan <he...@soluvas.com> wrote:
>
> > Hi,
> >
> > I don't like URL fragments either.
> > For unsupported browsers, I would prefer downgrading to normal stateful
> > AJAX.
> >
> > Hendy
> >
> > Hendy Irawan - on Twitter <http://twitter.com/hendybippo> - on LinkedIn<
> http://id.linkedin.com/in/hendyirawan>
> > Web Developer | Bippo Indonesia <http://www.bippo.co.id/> | Akselerator
> > Bisnis | Bandung
> >
> >
> > On Mon, Sep 23, 2013 at 7:19 PM, Martin Grigorov-4 [via Apache Wicket] <
> > ml-node+s1842946n4661445h93@n4.nabble.com> wrote:
> >
> >> Hi,
> >>
> >>
> >> On Mon, Sep 23, 2013 at 1:59 PM, Hendy Irawan <[hidden email]<
> http://user/SendEmail.jtp?type=node&node=4661445&i=0>>
> >> wrote:
> >>
> >> > Hi,
> >> >
> >> > The way I see it now this will enable a lot of our frontend pages to
> be
> >> > stateless.
> >> >
> >> > Currently http://www.tuneeca.com powered by Wicket 6.8.0 has mostly
> >> > stateful
> >> > frontend pages (except for HomePage, which we made the effort to be
> >> > stateless to reduce pagestore/session usage).
> >> >
> >> > Most of the "state" are used for paging, sorting, and filter, which we
> >> > happen to use Wicket's AJAX built-in support heavily (thanks Wicket!!
> >> :-) )
> >> > but of course this makes the pages has ?id in them.
> >> >
> >> > I think it'd be possible to encode all the "state" a page wants in,
> >> e.g. :
> >> >
> >> >
> >> >
> >>
> http://www.tuneeca.com/release/carribean_dream?lowerPrice=50000&upperPrice=200000&sort=name&page=2
> >> >
> >> > or perhaps:
> >> >
> >> >
> >> >
> >>
> http://www.tuneeca.com/release/carribean_dream/lowerPrice/50000/upperPrice/200000/sort/name/page/2
> >>
> >>
> >> Both of these urls won't work in IE 8/9/10 because these versions of IE
> >> do
> >> not support HTML5 History API.
> >> To support history you will need to use Url fragments, i.e. something
> >> like:
> >>
> >>
> >>
> http://www.tuneeca.com/release/carribean_dream?#lowerPrice/50000/upperPrice/200000/sort/name/page/2
> >> or
> >>
> >>
> http://www.tuneeca.com/release/carribean_dream?#lowerPrice=50000&upperPrice=200000&sort=name&page=2
> >>
> >>
> >>
> >> >
> >> > With the History API support it'd should be possible to do this, while
> >> > retaining four (!!) awesome characteristics :
> >> >
> >> > 1. AJAX - faster loading due to less bandwidth usage
> >> > 2. Bookmarkable - the URLs (+ parameters) are immediately bookmarkable
> >> and
> >> > consistent.
> >> >
> >>
> >> With the Url fragments this is not quite true.
> >> The url is bookmarkable but will require some extra JavaScript onload
> >> logic
> >> to make an Ajax call to the server after initially loading the page.
> >> Twitter used to use this approach but it didn't worked well. There are
> >> blog
> >> articles about the problems.
> >>
> >>
> >> > 3. Statelessness - faster loading (internally), which results in:
> >> >
> >>
> >> How exactly it will be faster ?
> >>
> >>
> >> > 4. Less session/pagestore usage - faster loading because less I/O,
> also
> >> > saves precious heap & disk space :-)
> >> >
> >>
> >> Those are not so precious these days.
> >> Actually developers' salary is bigger than their cost.
> >>
> >>
> >> >
> >> > Point 3 & 4 above are only possible with proper stateless
> links/buttons
> >> > etc.
> >> > (which I assume will be one of the improved features of Wicket 7?)
> >> >
> >>
> >> There are no such improvements at the moment.
> >>
> >> But there is
> >> http://central.maven.org/maven2/org/wicketstuff/wicketstuff-stateless/
> >>
> >>
> >> >
> >> > Of course I haven't yet made a Proof of concept of this... (sorry!)
> but
> >> > just
> >> > thinking about this made me excited. If this works out, Wicket 7's
> >> > definitely going to be the most awesome web framework of all (not that
> >> it
> >> > hasn't, mind you :-)).
> >> >
> >> > Hendy
> >> >
> >> >
> >> >
> >> >
> >> > --
> >> > View this message in context:
> >> >
> >>
> http://apache-wicket.1842946.n4.nabble.com/Wicket7-History-API-support-for-navigable-AJAX-pages-components-tp4660502p4661443.html
> >>
> >> > Sent from the Forum for Wicket Core developers mailing list archive at
> >> > Nabble.com.
> >> >
> >>
> >>
> >> ------------------------------
> >>  If you reply to this email, your message will be added to the
> >> discussion below:
> >>
> >>
> http://apache-wicket.1842946.n4.nabble.com/Wicket7-History-API-support-for-navigable-AJAX-pages-components-tp4660502p4661445.html
> >>  To unsubscribe from [Wicket7] History API support for navigable AJAX
> >> pages/components?, click here<
> http://apache-wicket.1842946.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4660502&code=aGVuZHlAc29sdXZhcy5jb218NDY2MDUwMnwxNTI0Njc4NzUy
> >
> >> .
> >> NAML<
> http://apache-wicket.1842946.n4.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml
> >
> >>
> >
> >
>
>
>
>
> --
> View this message in context:
> http://apache-wicket.1842946.n4.nabble.com/Wicket7-History-API-support-for-navigable-AJAX-pages-components-tp4660502p4661532.html
> Sent from the Forum for Wicket Core developers mailing list archive at
> Nabble.com.
>

Re: [Wicket7] History API support for navigable AJAX pages/components?

[Hendy Irawan <he...@soluvas.com>]

Good news!

I've created a proof-of-concept project using Wicket 6.10 :

https://github.com/ceefour/wicket-historyapi

There are 3 approaches:
1. redirect
2. stateless
3. history API

(Actually there should be a stateful approach too.)

The History API is using history.js (don't worry, HTML4 support is disabled
i.e. no hashbangs).

What I'd like to have is a hybrid approach that combines approach #1
(redirect, for non-supporting browsers e.g. IE10 & Googlebot) + #3 (history
API, for supporting browsers). Not sure how to do this yet....

As it is now, all these approaches require workarounds and non-standard
Wicket components, and especially the "stateless" approach aren't working
in certain situations.

It'd be great if the combined approach would work out-of-the-box with
Wicket 7.

And one more thing would be transitions and animations. This is not
exclusive to history API/stateless support but some support in core would
be very appreciated. e.g. an API such as this would be wonderful:

target.add( myComponent, Animation.fadeOut(250), Animation.fadeIn(400) );

Thank you.

Hendy


Hendy Irawan - on Twitter <http://twitter.com/hendybippo> - on
LinkedIn<http://id.linkedin.com/in/hendyirawan>
Web Developer | Bippo Indonesia <http://www.bippo.co.id/> | Akselerator
Bisnis | Bandung


On Mon, Sep 23, 2013 at 1:58 PM, Hendy Irawan <he...@soluvas.com> wrote:

> Hi,
>
> I don't like URL fragments either.
> For unsupported browsers, I would prefer downgrading to normal stateful
> AJAX.
>
> Hendy
>
> Hendy Irawan - on Twitter <http://twitter.com/hendybippo> - on LinkedIn<http://id.linkedin.com/in/hendyirawan>
> Web Developer | Bippo Indonesia <http://www.bippo.co.id/> | Akselerator
> Bisnis | Bandung
>
>
> On Mon, Sep 23, 2013 at 7:19 PM, Martin Grigorov-4 [via Apache Wicket] <
> ml-node+s1842946n4661445h93@n4.nabble.com> wrote:
>
>> Hi,
>>
>>
>> On Mon, Sep 23, 2013 at 1:59 PM, Hendy Irawan <[hidden email]<http://user/SendEmail.jtp?type=node&node=4661445&i=0>>
>> wrote:
>>
>> > Hi,
>> >
>> > The way I see it now this will enable a lot of our frontend pages to be
>> > stateless.
>> >
>> > Currently http://www.tuneeca.com powered by Wicket 6.8.0 has mostly
>> > stateful
>> > frontend pages (except for HomePage, which we made the effort to be
>> > stateless to reduce pagestore/session usage).
>> >
>> > Most of the "state" are used for paging, sorting, and filter, which we
>> > happen to use Wicket's AJAX built-in support heavily (thanks Wicket!!
>> :-) )
>> > but of course this makes the pages has ?id in them.
>> >
>> > I think it'd be possible to encode all the "state" a page wants in,
>> e.g. :
>> >
>> >
>> >
>> http://www.tuneeca.com/release/carribean_dream?lowerPrice=50000&upperPrice=200000&sort=name&page=2
>> >
>> > or perhaps:
>> >
>> >
>> >
>> http://www.tuneeca.com/release/carribean_dream/lowerPrice/50000/upperPrice/200000/sort/name/page/2
>>
>>
>> Both of these urls won't work in IE 8/9/10 because these versions of IE
>> do
>> not support HTML5 History API.
>> To support history you will need to use Url fragments, i.e. something
>> like:
>>
>>
>> http://www.tuneeca.com/release/carribean_dream?#lowerPrice/50000/upperPrice/200000/sort/name/page/2
>> or
>>
>> http://www.tuneeca.com/release/carribean_dream?#lowerPrice=50000&upperPrice=200000&sort=name&page=2
>>
>>
>>
>> >
>> > With the History API support it'd should be possible to do this, while
>> > retaining four (!!) awesome characteristics :
>> >
>> > 1. AJAX - faster loading due to less bandwidth usage
>> > 2. Bookmarkable - the URLs (+ parameters) are immediately bookmarkable
>> and
>> > consistent.
>> >
>>
>> With the Url fragments this is not quite true.
>> The url is bookmarkable but will require some extra JavaScript onload
>> logic
>> to make an Ajax call to the server after initially loading the page.
>> Twitter used to use this approach but it didn't worked well. There are
>> blog
>> articles about the problems.
>>
>>
>> > 3. Statelessness - faster loading (internally), which results in:
>> >
>>
>> How exactly it will be faster ?
>>
>>
>> > 4. Less session/pagestore usage - faster loading because less I/O, also
>> > saves precious heap & disk space :-)
>> >
>>
>> Those are not so precious these days.
>> Actually developers' salary is bigger than their cost.
>>
>>
>> >
>> > Point 3 & 4 above are only possible with proper stateless links/buttons
>> > etc.
>> > (which I assume will be one of the improved features of Wicket 7?)
>> >
>>
>> There are no such improvements at the moment.
>>
>> But there is
>> http://central.maven.org/maven2/org/wicketstuff/wicketstuff-stateless/
>>
>>
>> >
>> > Of course I haven't yet made a Proof of concept of this... (sorry!) but
>> > just
>> > thinking about this made me excited. If this works out, Wicket 7's
>> > definitely going to be the most awesome web framework of all (not that
>> it
>> > hasn't, mind you :-)).
>> >
>> > Hendy
>> >
>> >
>> >
>> >
>> > --
>> > View this message in context:
>> >
>> http://apache-wicket.1842946.n4.nabble.com/Wicket7-History-API-support-for-navigable-AJAX-pages-components-tp4660502p4661443.html
>>
>> > Sent from the Forum for Wicket Core developers mailing list archive at
>> > Nabble.com.
>> >
>>
>>
>> ------------------------------
>>  If you reply to this email, your message will be added to the
>> discussion below:
>>
>> http://apache-wicket.1842946.n4.nabble.com/Wicket7-History-API-support-for-navigable-AJAX-pages-components-tp4660502p4661445.html
>>  To unsubscribe from [Wicket7] History API support for navigable AJAX
>> pages/components?, click here<http://apache-wicket.1842946.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4660502&code=aGVuZHlAc29sdXZhcy5jb218NDY2MDUwMnwxNTI0Njc4NzUy>
>> .
>> NAML<http://apache-wicket.1842946.n4.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>>
>
>




--
View this message in context: http://apache-wicket.1842946.n4.nabble.com/Wicket7-History-API-support-for-navigable-AJAX-pages-components-tp4660502p4661532.html
Sent from the Forum for Wicket Core developers mailing list archive at Nabble.com.

Re: [Wicket7] History API support for navigable AJAX pages/components?

[Martin Grigorov <mg...@apache.org>]

Hi,


On Mon, Sep 23, 2013 at 1:59 PM, Hendy Irawan <he...@soluvas.com> wrote:

> Hi,
>
> The way I see it now this will enable a lot of our frontend pages to be
> stateless.
>
> Currently http://www.tuneeca.com powered by Wicket 6.8.0 has mostly
> stateful
> frontend pages (except for HomePage, which we made the effort to be
> stateless to reduce pagestore/session usage).
>
> Most of the "state" are used for paging, sorting, and filter, which we
> happen to use Wicket's AJAX built-in support heavily (thanks Wicket!! :-) )
> but of course this makes the pages has ?id in them.
>
> I think it'd be possible to encode all the "state" a page wants in, e.g. :
>
>
> http://www.tuneeca.com/release/carribean_dream?lowerPrice=50000&upperPrice=200000&sort=name&page=2
>
> or perhaps:
>
>
> http://www.tuneeca.com/release/carribean_dream/lowerPrice/50000/upperPrice/200000/sort/name/page/2


Both of these urls won't work in IE 8/9/10 because these versions of IE do
not support HTML5 History API.
To support history you will need to use Url fragments, i.e. something like:

http://www.tuneeca.com/release/carribean_dream?#lowerPrice/50000/upperPrice/200000/sort/name/page/2
or
http://www.tuneeca.com/release/carribean_dream?#lowerPrice=50000&upperPrice=200000&sort=name&page=2


>
> With the History API support it'd should be possible to do this, while
> retaining four (!!) awesome characteristics :
>
> 1. AJAX - faster loading due to less bandwidth usage
> 2. Bookmarkable - the URLs (+ parameters) are immediately bookmarkable and
> consistent.
>

With the Url fragments this is not quite true.
The url is bookmarkable but will require some extra JavaScript onload logic
to make an Ajax call to the server after initially loading the page.
Twitter used to use this approach but it didn't worked well. There are blog
articles about the problems.


> 3. Statelessness - faster loading (internally), which results in:
>

How exactly it will be faster ?


> 4. Less session/pagestore usage - faster loading because less I/O, also
> saves precious heap & disk space :-)
>

Those are not so precious these days.
Actually developers' salary is bigger than their cost.


>
> Point 3 & 4 above are only possible with proper stateless links/buttons
> etc.
> (which I assume will be one of the improved features of Wicket 7?)
>

There are no such improvements at the moment.

But there is
http://central.maven.org/maven2/org/wicketstuff/wicketstuff-stateless/


>
> Of course I haven't yet made a Proof of concept of this... (sorry!) but
> just
> thinking about this made me excited. If this works out, Wicket 7's
> definitely going to be the most awesome web framework of all (not that it
> hasn't, mind you :-)).
>
> Hendy
>
>
>
>
> --
> View this message in context:
> http://apache-wicket.1842946.n4.nabble.com/Wicket7-History-API-support-for-navigable-AJAX-pages-components-tp4660502p4661443.html
> Sent from the Forum for Wicket Core developers mailing list archive at
> Nabble.com.
>

Re: [Wicket7] History API support for navigable AJAX pages/components?

[Hendy Irawan <he...@soluvas.com>]

I updated the JIRA (https://issues.apache.org/jira/browse/WICKET-5290) to
note potential uses cases as follows:

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. 

Hendy




--
View this message in context: http://apache-wicket.1842946.n4.nabble.com/Wicket7-History-API-support-for-navigable-AJAX-pages-components-tp4660502p4661444.html
Sent from the Forum for Wicket Core developers mailing list archive at Nabble.com.

Re: [Wicket7] History API support for navigable AJAX pages/components?

[Hendy Irawan <he...@soluvas.com>]

Hi,

The way I see it now this will enable a lot of our frontend pages to be
stateless.

Currently http://www.tuneeca.com powered by Wicket 6.8.0 has mostly stateful
frontend pages (except for HomePage, which we made the effort to be
stateless to reduce pagestore/session usage).

Most of the "state" are used for paging, sorting, and filter, which we
happen to use Wicket's AJAX built-in support heavily (thanks Wicket!! :-) )
but of course this makes the pages has ?id in them.

I think it'd be possible to encode all the "state" a page wants in, e.g. :

http://www.tuneeca.com/release/carribean_dream?lowerPrice=50000&upperPrice=200000&sort=name&page=2

or perhaps:

http://www.tuneeca.com/release/carribean_dream/lowerPrice/50000/upperPrice/200000/sort/name/page/2

With the History API support it'd should be possible to do this, while
retaining four (!!) awesome characteristics :

1. AJAX - faster loading due to less bandwidth usage
2. Bookmarkable - the URLs (+ parameters) are immediately bookmarkable and
consistent.
3. Statelessness - faster loading (internally), which results in:
4. Less session/pagestore usage - faster loading because less I/O, also
saves precious heap & disk space :-)

Point 3 & 4 above are only possible with proper stateless links/buttons etc.
(which I assume will be one of the improved features of Wicket 7?)

Of course I haven't yet made a Proof of concept of this... (sorry!) but just
thinking about this made me excited. If this works out, Wicket 7's
definitely going to be the most awesome web framework of all (not that it
hasn't, mind you :-)).

Hendy




--
View this message in context: http://apache-wicket.1842946.n4.nabble.com/Wicket7-History-API-support-for-navigable-AJAX-pages-components-tp4660502p4661443.html
Sent from the Forum for Wicket Core developers mailing list archive at Nabble.com.

Re: [Wicket7] History API support for navigable AJAX pages/components?

[Martin Grigorov <mg...@apache.org>]

On Mon, Aug 5, 2013 at 6:35 PM, Igor Vaynberg <ig...@gmail.com>wrote:

> On Sun, Aug 4, 2013 at 1:16 AM, Martin Grigorov <mgrigorov@apache.org
> >wrote:
>
> > On Sat, Aug 3, 2013 at 5:23 PM, Igor Vaynberg <igor.vaynberg@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.
>

I think this use case will end with StalePageException for the second
request.
Since this is non-Ajax request the first request will increase the
renderCount and the second will just repaint the page with the new
renderCount and the new pageId, but won't do any action on it


> 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.
>

what you describe looks to me like the following:

prerequisites:
- the page is stored as byte[] in the HttpSession (currently it is a live,
detached instance)
- PageAccessSynchronizer is not in use

since after deserialization the page instances for pageId=5 are different
there is no need to synchronize the access to them and each request can do
whatever is needed.

of course the big problem with this approach is working with stale data -
request 1 removes some data, and request 2 tries to use it


>
> -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 <mgrigorov@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 <
> mgrigorov@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.
> > > > >>
> > > > >
> > > > >
> > > >
> > >
> >
>

Re: [Wicket7] History API support for navigable AJAX pages/components?

[Igor Vaynberg <ig...@gmail.com>]

On Sun, Aug 4, 2013 at 1:16 AM, Martin Grigorov <mg...@apache.org>wrote:

> On Sat, Aug 3, 2013 at 5:23 PM, Igor Vaynberg <igor.vaynberg@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 <mgrigorov@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 <mgrigorov@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.
> > > >>
> > > >
> > > >
> > >
> >
>

Re: [Wicket7] History API support for navigable AJAX pages/components?

[Martin Grigorov <mg...@apache.org>]

On Sat, Aug 3, 2013 at 5:23 PM, Igor Vaynberg <ig...@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 <mgrigorov@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 <mgrigorov@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.
> > >>
> > >
> > >
> >
>

Re: [Wicket7] History API support for navigable AJAX pages/components?

[Igor Vaynberg <ig...@gmail.com>]

* 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.

* 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.

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

-igor


On Thu, Aug 1, 2013 at 1:32 AM, Martin Grigorov <mg...@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 <mgrigorov@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.
> >>
> >
> >
>

Re: [Wicket7] History API support for navigable AJAX pages/components?

[Martin Grigorov <mg...@apache.org>]

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 <mg...@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.
>>
>
>

Re: [Wicket7] History API support for navigable AJAX pages/components?

[Martin Grigorov <mg...@apache.org>]

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.
>