I agree with Ed regarding URL decoration. For portlets, this would have to be done on the server because the portlet container is in full control of URLs and URL query-string parameters. I don't see how this could be implemented as a client JavaScript responsibility.
Also, should the windowId query parameter requirement be extended to ExternalContext.encodePartialActionURL(String) as well? The windowId would then appear in the javax.faces.encodedURL hidden field value.
On May 31, 2012, at 11:54 AM, Leonardo Uribe wrote:
> Hi
>
> 2012/5/29 Edward Burns <edward.burns_at_oracle.com>:
>> 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.
>>
>
> In fact I'm more worried about the call to FacesContext.getCurrentInstance(),
> because it is necessary to call
> ClientWindow.isClientWindowUrlQueryParameterEnabled(facesContext). Ok,
> it is possible to cache FacesContext at ExternalContext level, but I agree the
> best is prevent to create String instances over and over, specially in
> this place,
> which is called very often.
>
> The concern about use the query param is that parameter is only relevant for the
> "actors" involved into the ClientWindow algorithm, so whatever name used,
> there is no need to hard code it into the spec. Instead, it sound better to
> let the RenderKit choose the query parameter name (if used).
> Obviously, that affects
> ClientWindow.decode(), but please note there should be a "contract" between
> the RenderKit technology used and the ClientWindow implementation.
>
>> 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.
>>
>
> Ok.
>
>> 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.
>>
>
> In theory it is also possible to use decode() to render some temporal output
> and then call facesContext.responseComplete(). I have checked it and it
> works, but the listeners and flash initializer from restore view phase are
> executed before the condition is detected. Maybe it is necessary to add
> some lines into the spec and adds a check for responseComplete in
> lifecycle.execute(), as it is done for example
> in lifecycle.render()
>
>> 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.
>>
>
> Sounds good, because any processing related to ClientWindow could be
> done in that place, just like with the state hidden field.
>
>> * 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?
>
> It is ok for me.
>
> regards,
>
> Leonardo Uribe
>>
>> Ed
>> --
>> | edward.burns_at_oracle.com | office: +1 407 458 0017
>> | homepage: | http://ridingthecrest.com/