On Tue, May 29, 2012 at 11:21 PM, Edward Burns <edward.burns_at_oracle.com>wrote:
> Leonardo Uribe, Mark Struberg and I had some discussion on ##jsf IRC
> about this issue today and I'd like to continue the discussion here.
> The intent of the discussion was to more cleanly allocate
> responsibilites among the players in the ClientWindow feature.
>
> SECTION: Current spec
>
> Hyperlink URL Decoration
>
> * ExternalContext.encodeActionURL() is currently responsible for
> ensuring that any hyperlinks that need a ClientWindow query parameter
> get one. Doing it here has a performance benefit because we don't
> need to pull apart the URL to get the query string again. If we were
> to move the responsibility for URL decoration out of here to somewhere
> else, we'd probably have to re-extract the query string, which would
> take time.
>
> Per-Use URL Decoration opt-out
>
> * Responsibility is shared between Renderers that render hyperlinks and
> the ClientWindow. Such renderers must call
> ClientWindow.disableClientWindowUrlQueryParameter() before rendering
> the link and calling
> ClientWindow.enableClientWindowUrlQueryParameter() after rendering the
> link.
>
> Hidden Field Rendering
>
> * Responsibility is shared between PartialViewContext and
> ResponseStateManager.
>
> Decoding the ClientWindow from the incoming request
>
> * ClientWindow.decode() is responsible for inspecting the incoming
> request and getting a value to return from ClientWindow.getId(). The
> spec says exactly how to get the value, and requires a value to be
> synthesized if none is found in the incoming request.
>
> SECTION: Discussion points
>
> * Hyperlink URL Decoration
>
> Mark and Leonardo want to make it so Hyperlink URL decoration is
> entirely a RenderKit concern. * They proposed an entirely JavaScript
> based URL decoration system* where the decoration does not happen on the
> server at all, and instead is performed on the client.
I understand, most mobile or embedded devices may not even have a browser
or not be the main target, but could there be devices without JavaScript we
nevertheless want to allow running JSF?
> To make this
> happen, we need some kind of indicator so the JavaScript can tell which
> hyperlinks must be decorated. This approach is mutually exclusive with
> doing URL decoration on the server side because URL decoration is done
> when we are generating the query string, but the indicator would be
> conveyed in some other way, and MUST NOT be in the query string as sent
> from the server side. Initially, I was fond of this approach but after
> looking into how it would be done, I don't see how we can do it without
> introducing a JavaScript framework dependency in the implemenation.
> This is because window.onload is fraught with cross-browser concerns.
> Therefore, I think it's more reliable to continue to have URL decoration
> done on the server.
>
> We can still shift around the responsibilities though. Leonardo notes
> that all of these four things are rendering technology specific in some
> way, and thus suggested a new class, ClientWindowRendererStrategy, that
> would have responsibility at least for the Decoration, and maybe even
> more.
>
> I counter here with the suggestion that this behavior be added on to the
> ResponseStateManager, whose charter is already:
>
> ResponseStateManager is the helper class to StateManager that knows
> the specific rendering technology being used to generate the
> response. It is a singleton abstract class, vended by the
> RenderKit. This class knows the mechanics of saving state, whether it
> be in hidden fields, session, or some combination of the two.
>
> So I propose we add a method to ResponseStateManager,
> getClientWindowUrlQueryParameter(). This method assumes the
> responsibilities currently specified on
> ExternalContext.encodeActionURL(), and, fact, is called from that
> method.
>
> * Per-Use URL Decoration opt-out
>
> I propose we drop ClientWindow.disableClientWindowUrlQueryParameter(),
> ClientWindow.enableClientWindowUrlQueryParameter(), and
> isClientWindowUrlQueryParameterEnabled(). Instead, we require the
> places that currently use those methods to call
> UIComponent.getCurrent{Composite}Component() and inspect the value of
> its "disableClientWindow" attribute.
>
> * Hidden Field Rendering
>
> I propose we keep the existing spec here.
>
> Is this ok?
>
> Ed
> --
> | edward.burns_at_oracle.com | office: +1 407 458 0017
> | homepage: | http://ridingthecrest.com/
>
--
Werner Keil | JCP Executive Committee Member | Eclipse UOMo Lead
Twitter @wernerkeil | #Java_Social | #EclipseUOMo | #OpenDDR
Skype werner.keil | Google+ gplus.to/wernerkeil
* Dutch Mobile Conference: June 8 2012, Amsterdam, Netherlands. Werner
Keil, JCP EC Member, OpenDDR Evangelist will present "OpenDDR"
* Eclipse DemoCamp Hamburg: June 14 2012, Hamburg, Germany. Werner Keil,
Eclipse UOMo Lead will present "Using Xtext/TS for type-safe DSLs"
* Eclipse DemoCamp Vienna: June 22 2012, Vienna, Austria. Werner Keil,
Eclipse UOMo Lead will present "Using Xtext/TS for type-safe DSLs"