Mike -

michael freedman wrote On 3/4/2009 6:00 PM ET:
This version of the spec doesn't seem to include a number of topics we have been discussing the past few weeks, including page parameters and Ajax changes (to better run in a portlet environment).

It might help to gather the outstanding portlet-related issues in one place.  IIRC, these include:

1. UIViewRoot NamingContainer support

Your #1 below.

2. Ajax postback URL

When running in portlet environments, Ajax requests need to post back to a different URL - ie. not the form's action URL, but an URL that is specially encoded by the portlet bridge.

3. View state param issues

Two issues here:

A. Duplicate ids
B. Control over which view state param fields are updated after an Ajax request.

Seems like B is more of a portlet issue - A is just a generic HTML validation issue, not specific to portlets.

Are there any other issues?

BTW, if we are going to do #1 (ie. make UIViewRoot a conditional naming container like UIForm), I would very much like to see a new contract/interface for such conditional naming container components.  The reason that I care is because UIForm's special "prependId" behavior ended up complicating our visitTree() implementation - ie. we ended up having to introduce a special UIForm.visitTree() override in order to take the prependId behavior into account.  If other components are going to support similar behavior, providing an interface with an isPrependId() method would allow us to simplify tree visiting - I believe to the point where we just have a single visitTree() implementation in UIComponentBase() that handles non-NamingContainers, NamingContainers and also "conditional" NamingContainers.

Andy


  When do you expect a review draft that includes these more recent changes?  For the draft I have the following few comments:
  1. Until I hear a yeah or nay I would like to continue to recommend the changes I proposed making javax.faces.component.UIViewRoot a NamingContainer that implements portlet namespacing when run/accessed in portlet requests.
  2. Section 14.1 (Ajax):  its not clear whether any hidden fields other than javax.faces.ViewState are included in ajax requests by jsf.ajax.getViewState.  The HTML successful controls doc says they may be included but that seems too loose.  Portlets need some accommodation to support the following use case:
    An Ajax using JSF portlet is included in an Ajax using JSF consumer page by a consumer defined process that inlines the portlet.  By inlining I mean the consumer parses the portlet markup, removes/rewrites the target of <form> elements as hidden fields (to avoid the embeded form problem), and namespaces all the form's fields so that when the consumers page is submitted it can decode those fields pertaining to this portlet.  The outcome of this process is the hidden field name = "javax.faces.ViewState" is rewriten as name = "ns:javax.faces.ViewState".  When the overall page is submitted we need to ensure this hidden field is submitted whenever any of the portlet's input fields would also be submitted.  One easy way to do this is to submit all the hidden fields as part of the form state.

    Note:  if we make progress on the active discussion regarding namespacing this field, the
  3. Section 14.2.3: typo -- the description references jsf.viewState but it looks like it means to reference jsf.getViewState.
   -Mike-



Roger Kitain wrote:
I've uploaded a spec snapshot to

https://javaserverfaces-spec-eg.dev.java.net/files/documents/2091/127938/jsf-spec-2.0-20090227.zip

Please review this in detail, because the next one is going out to JCP on March 6, 2009.

Roger