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