Hi
2012/2/28 Edward Burns <edward.burns_at_oracle.com>:
>>>>>> On Mon, 27 Feb 2012 14:59:46 -0500, Leonardo Uribe <lu4242_at_gmail.com> said:
>
> LU> "url" mode works as described on:
>
> LU> See: Embedding a window-id in the URL
>
> Orchestra> Users must then be prevented from using "open in new window"
> Orchestra> on links containing the id, as that would copy the magic
> Orchestra> window-id parameter and both windows would appear to the
> Orchestra> server to be the same window. This can be done by setting the
> Orchestra> "href" parameter of these links to "javascript:0", and adding
> Orchestra> an onclick attribute that actually does the navigation by
> Orchestra> assigning the desired url to property "window.location". The
> Orchestra> FireFox browser simply does not render the "open in new
> Orchestra> window" option when the href is a javascript link; Internet
> Orchestra> Explorer does render the menu option but the newly opened
> Orchestra> window is always blank.
>
> I'm not opposed to doing this, but this would seem to impact the
> specification for the javax.faces.Commandjavax.faces.Link and
> javax.faces.Outputjavax.faces.Link renderers right? And both of those
> renderers would have to have some kind of ability to ask, "Is the
> WindowIdMode url mode?" and if so, they'd have to take the specific
> action you propose, right?
>
Well, really MyFaces Orchestra does not do the last part proposed.
The same page says this:
"... Orchestra currently implements the "Embedding a window-id in
the URL" approach. It overrides method ServletResponse.encodeURL
to automatically insert a query-parameter named
"conversationContext" into every url rendered in the page. This can
be disabled for specific links using the JSF
ox:separateConversationContext tag around the link; the link url
will not have the magic parameter in it and therefore the request
will cause a new context to be allocated on the server. ..."
In theory, the idea is url mode works just like Orchestra, without any
hack over javax.faces.Link renderer, to have an alternative when
javascript is disabled. Note there is no "perfect" solution for this issue,
but Orchestra has proved this strategy can be valuable and acceptable.
Is up to the Expert Group to decide what to do here. In theory it
is necessary to provide a way to indicate if a link should add the
windowId or not (like h:link includeViewParams?
includeWindowIdParam?).
> LU> "client" mode is the one derived from CODI, which also uses an url
> LU> query param, but uses the script to generate the unique id from the
> LU> client side. Maybe Mark Struberg or Gerhard knows better than me how
> LU> this mode should work.
>
> I hope they do, and until someone can post the specifics here, I'll
> leave "client" mode out of the spec.
>
@Gerhard or Mark : could you help us with this description?
In my understanding, the client mode just works like the url mode but
in this case the windowId is generated on the client side using
the page that use javascript to calculate it and redirect the request,
adding the windowId as a query parameter.
If there is a link that creates a new window, the idea is do not add
the windowId on that link just like with url mode. In that way,
when the new tab/window is created, the process with the page
and the javascript code will take effect.
When there is a simple GET-GET navigation, the windowId will be
transported as a query param. As simple as that.
> ACTION: Leonardo, please let me know what you think the best way to
> specify the rendering of the magic window-id parameter.
>
I was thinking on:
- Use a hidden field called javax.faces.WindowId. With this field, it is easy
to identify easily from the client side which forms needs to be updated with
the new state in ajax operations. Use javax.faces.ViewState "id" to send
the windowId can do the job too, because the requeriment from the client
side is have a way to identify the windowId and in that way identify the states
that needs to be updated, but I feel the other way is more simple.
Note I'm saying here that "field" mode should be used too when using
"url" or "client" mode.
- The hidden field javax.faces.WindowId has precedence over windowId
query param, so if the two are found, javax.faces.WindowId is used because
* Browsers do not support an operation to do "submit form and
show result in other window"
* Bookmarking does not store form data.
* When a POST is performed the url of the post is displayed in the
browser navigation bar, but not the form field values so it is not
stored by a later "bookmark" operation.
- In theory windowId is similar to JSESSIONID but with a narrower
scope. In servlet 2.5 this was the description for
HttpServletResponse.encodeURL()
"... Encodes the specified URL by including the session ID in it, or, if
encoding is not needed, returns the URL unchanged. The implementation
of this method includes the logic to determine whether the session ID
needs to be encoded in the URL. For example, if the browser supports
cookies, or session tracking is turned off, URL encoding is unnecessary. ..."
"... For robust session tracking, all URLs emitted by a servlet should
be run through this method. Otherwise, URL rewriting cannot be used
with browsers which do not support cookies. ..."
Orchestra wrapped that method because in servlet 2.5, it was the
suggested mode to deal with that.
What we need is a way to append the windowId query param to
generated URLs in a way that links that requires it will have it (maybe
the default is add it to all links that requires session to work) and
others like resource links or links that suppose to create a new window
just does not have it.
From spec point of view, it is necessary to keep a query param
name ("windowId") and a hidden field ("javax.faces.WindowId") to
transport the windowId value. Then we need some update the API,
maybe in ExternalContext and in other places, to allow the developer
to customize which generated links will transport the windowId, and
which other will not.
According to the Rendekit and to the mode used, the code that
execute the link (h:link, ... ) can change, but this is specific to the
Renderkit. It is clear there is a relationship between Window
object and the renderkit, but it is difficult to establish a "contract"
here, because it depends on the mode used.
regards,
Leonardo
> Thanks,
>
> Ed
>
> --
> | edward.burns_at_oracle.com | office: +1 407 458 0017
> | homepage: | http://ridingthecrest.com/