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:
- 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.
- 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
- 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