[jsr-314-open] Portlet support - remaining issues [Was: JSF 2.0 Spec Snapshot]

[Andy Schwartz]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jsr-314-open-mirror/attachments/20090305/455e2600/attachment.html