[
https://issues.apache.org/jira/browse/WICKET-3813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13720571#comment-13720571
]
Hendy Irawan edited comment on WICKET-3813 at 7/26/13 9:32 AM:
---------------------------------------------------------------
So the proposal is considered? Awesome! (*mentalgasm*)
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).
Now that we're in this.. I kindly wonder if there could be plans to make
push/Atmosphere/WebSocket more "first class" in Wicket 7 than 6. Since we've
been using wicket-atmosphere quite intensively in a few projects.
was (Author: ceefour):
So the proposal is considered? Awesome! (*mentalgasm*)
What I ever used is Backbone. Which is a great all around library.
Breadcrumb components would benefit greatly from History API support (and is
probably its main use case).
Now that we're in this.. I kindly wonder if there could be plans to make
push/Atmosphere/WebSocket more "first class" in Wicket 7 than 6. Since we've
been using wicket-atmosphere quite intensively in a few projects.
> Support for device and fallback device specific layout
> ------------------------------------------------------
>
> Key: WICKET-3813
> URL: https://issues.apache.org/jira/browse/WICKET-3813
> Project: Wicket
> Issue Type: New Feature
> Components: wicket
> Reporter: Bruno Borges
> Attachments: devicelayout.patch, DeviceStreamLocator.java
>
>
> Wicket does a great job at locating resources based on variation, style and
> location. The current way of locating HTML resources is done by the following
> schema:
> Page[_variation][_style][_locale].extension
> where:
> * variation is per Component
> * style and locale are per Session
> The feature proposed here is to add another section, separated by a single
> dot, to be used specifically for HTML files:
> Page[_variation][_style][_locale][.device].extension
> The use case that requires this is one where an user's device is identified
> as an Android phone and so one could set Session.get().setDevice("android");
> Inside ResourceStreamLocator, the current algorithm can just add that as an
> array of extensions to iterate.
> Consider the HomePage:
> - HomePage.html
> - HomePage.m.html
> - HomePage.android.html
> For the Android user, HomePage will render HomePage.android.html file.
> A desktop user will render HomePage.html because
> Session.get().isStandardDevice(); will return true
> To support an iPhone user, one could set
> Session.get().setFallbackDevice("m"); and so, will render HomePage.m.html
> which could be a simplier version for other phones but Android.
> I've attached an example of DeviceStreamLocator
--
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
