Summary: Please correct me if I'm wrong but all that remains for this
feature in JSF 2.2 is to concretely specify url-mode and make it
reasonably easy to override and decorate to provide custom-mode.
LU> "url" mode works as described on:
LU> See: Embedding a window-id in the URL
EB> I'm not opposed to doing this, but this would seem to impact the
EB> specification for the javax.faces.Commandjavax.faces.Link and
EB> javax.faces.Outputjavax.faces.Link renderers right?
[...]
LU> the URL" approach. It overrides method ServletResponse.encodeURL
LU> to automatically insert a query-parameter named
LU> "conversationContext" into every url rendered in the page. This can
LU> be disabled for specific links using the JSF
LU> ox:separateConversationContext tag around the link;
We are not able to require such an override out of respect for portlet
requirements. For CommandLink, the hidden field will work because our
existing specification makes the CommandLink act like a postback. That
leaves us with OutputLink and OutcomeTargetLink. These both pass
through ExternalContext.encodeResourceURL(). Note that other callsites
use ExternalContext.encodeResourceURL() for which it does not make sense
to do this URL appending, but in those cases appending the query string
will not cause any harm.
LU> In theory it is necessary to provide a way to indicate if a link
LU> should add the windowId or not (like h:link includeViewParams?
LU> includeWindowIdParam?).
Here is a new requirement that hasn't been clearly articulated anywhere
else but in your email just now, Leonardo. I have just added it to the
proposal.
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.
EB> I hope they do, and until someone can post the specifics here, I'll
EB> leave "client" mode out of the spec.
It seems like the 2 March revision of the proposal *does* leave it out
of the spec, instead requesting that we specify a "custom-Mode".
EB> ACTION: Leonardo, please let me know what you think the best way to
EB> specify the rendering of the magic window-id parameter.
LU> I was thinking on:
LU> - Use a hidden field called javax.faces.WindowId. With this field,
LU> it is easy to identify easily from the client side which forms needs
LU> to be updated with the new state in ajax operations. Use
LU> javax.faces.ViewState "id" to send the windowId can do the job too,
LU> because the requeriment from the client side is have a way to
LU> identify the windowId and in that way identify the states that needs
LU> to be updated, but I feel the other way is more simple.
LU> Note I'm saying here that "field" mode should be used too when using
LU> "url" or "client" mode.
Ok, good, I'm glad to see that the work we did on "field" mode is
useful.
LU> - The hidden field javax.faces.WindowId has precedence over windowId
LU> query param, so if the two are found, javax.faces.WindowId is used because
Thank you for stating that requirement so clearly.
LU> What we need is a way to append the windowId query param to
LU> generated URLs in a way that links that requires it will have it (maybe
LU> the default is add it to all links that requires session to work) and
LU> others like resource links or links that suppose to create a new window
LU> just does not have it.
A convenient side-effect of the way I have it currently specified is
that the windowId will never interfere with the serving of resource
requests because I added a new method to Lifecycle: attachWindow(), that
is never called when serving a resource request.
LU> From spec point of view, it is necessary to keep a query param
LU> name ("windowId") and a hidden field ("javax.faces.WindowId") to
LU> transport the windowId value. Then we need some update the API,
LU> maybe in ExternalContext and in other places, to allow the developer
LU> to customize which generated links will transport the windowId, and
LU> which other will not.
Yes. I have an idea for that.
LU> According to the Rendekit and to the mode used, the code that
LU> execute the link (h:link, ... ) can change, but this is specific to the
LU> Renderkit. It is clear there is a relationship between Window
LU> object and the renderkit, but it is difficult to establish a "contract"
LU> here, because it depends on the mode used.
Yes, we'll just have to fan out the contract definition to all the
places that intersect with the feature.
>>>>> On Fri, 02 Mar 2012 10:31:33 +0100, Werner Punz <werner.punz_at_gmail.com> said:
WP> Hence here is an updated proposal which fixes the issues which were
WP> accidentally pushed in. (WindowId per portlet is not needed)
WP>
https://cwiki.apache.org/confluence/display/MYFACES/WindowId+Proposal
This proposal still is not written in terms of the API that we have in
the spec as of 23 Feb. I have no way of knowing what that means with
respect to the current spec. Are you saying that in spite of the API
currently in the spec, you still want the WindowId+Proposal API instead?
Or is it the case that WindowId+Proposal hasn't been re-written in terms
of the spec as of 23 Feb? Also, when I look at WindowId+Proposal, there
are several things that I still don't think we need, for example
doPrePhaseActions()
doPostPhaseActions()
encodeXYZ
If, as I suspect, we are close to having this one completed for 2.2, we
can just do the rest of the work in the real spec and we don't need to
update WindowId+Proposal any more. If I'm wrong and we need a lot more
discussion, then it would be very helpful if WindowId+Proposal can be
re-written in terms of what's currently in the spec.
WP> 1 Status quo CODI:
WP> ------------------------------------------------
WP> 1.1 General Definitions regarding Window-ID
WP> ------------------------------------------------------------
WP> a) a window-id always refers to the tab (because it should/can be stored
WP> in the browsers window.name)
Ok this is another new requirement. Neil, I need your portlet input on
this, because it doesn't seem safe that I can say something like,
"jsf.js must make it so window.name is set to the window id."
WP> 1.2 Modes and special cases
WP> ---------------------------------------
WP> 1) no mode: no window-id is generated - legacy mode
WP> 2) url-Mode: the window-id is stored in the browser url
WP> hidden fields are shadowed into the forms also to keep the window-id
WP> support for post requests.
WP> windowId parameters are added to http get links.
WP> Server side the windowId needs to be processed over the sent windowId
WP> parameters.
WP> This is even the same for Portlet cases since the window-id has
WP> a referential pattern of 1:n to the scopes
WP> The same goes for sub scopes.
WP> If a new tab is opened a Javascript script detects that use case and
WP> basically re-renders the page with a new window-id dedicated to the tab.
WP> How that is done is up to the implementation. The basic implementation
WP> is to check for an empty or non-matching window.name and then redirect
WP> the page without a window-id in the url to force a new one.
Werner, anything you could do to be more specific on this would be very
helpful.
WP> 3) custom-Mode:
WP> Allows to use a custom mode provided by the JSF implementation or a
WP> custom RenderKit.
WP> Value: custom:[name of the mode]
WP> TBD
What happened to 4)?
WP> 5) Bookmark case or a href ... target=_new: This is handled in CODI by
WP> opening a new window-id or recycling the old one (bookmarking case with
WP> same windowid in the bookmark as the existing one)
Can you please help me understand what you mean here? When you say
"recycle the old one" that implies we keep some cache of allocated
window ids, that seems heavyweight.
WP> 2. Status quo of the spec discussion compared to CODI:
WP> ---------------------------------------------------------------------------
WP> a) URL mode: checked is discussed.
WP> b) overriding the URL not yet fully discussed: since it opens another
WP> can of worms (f)
WP> d) Open in new tab script: soon under discussion
Great, that's what I was asking for above.
WP> e) hidden field only mode: Breaks e.g. the get requests and browser
WP> refresh, therefore not doable.
Just for my own information, can you please explain where hidden-field
mode only fails? I trust you that there are cases where it fails, and I
have committed to specifying url-mode, but I need to understand why
hidden-field mode is insufficient.
WP> f) jsf.getWindowId can be simplified (is now in the proposal) if (b) is
WP> omitted or postponed, otherwise it needs to be investigated, if the
WP> current implementation can hold. The entire code was programmed under
WP> the assumption that we have a window-id per Portlet use case, which
WP> cannot hold for (d) see also (g)
Ok. Well, I guess I'll wait for your clarifaction on this one.
WP> g) Ajax protocol ViewRoot either redundant, or in case of (b), cannot
WP> work on ViewRoot level
WP> because single forms can if override is enabled be updated with
WP> different ViewRoots.
WP> (my mistake i was under the wrong assumption between window-id and scope
WP> and because of (g) )
Are you saying we don't need <update
id="<VIEW_ROOT_CONTAINER_CLIENTID><SEP><javax.faces.WindowId<SEP><UNIQUE_PER_VIEW_NUMBER">
any more?
WP> h) window-id per Portlet, is there a use case for that one? Especially
WP> since it breaks the new
WP> tab detection jsf.getWindowId can hold for (g)
WP> i) server side part of the window-id handling, where to be rendered,
WP> under discussion
WP> h) open point: what to do with the a hrefs and pages where you don´t
WP> want to have a window id. Should a link to a different window-id be
WP> possible, how can you turn it off/on.
I am willing to entertain per-link disablement, but not per-page.
NG> If all portlets on a page were in a single WAR file, then the new
NG> ExternalContext.getWindowMap() could use the
Where are you seeing ExternalContext.getWindowMap()? It's not in the
current spec and it's not in WindowId+Proposal.
Ed
--
| edward.burns_at_oracle.com | office: +1 407 458 0017
| homepage: | http://ridingthecrest.com/