[jsr-314-open] Portlet support - remaining issues [Was: JSF 2.0 Spec Snapshot]
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/...
>
>
> Please review this in detail, because the next one is going out to
> JCP on March 6, 2009.
>
> Roger
Attachments:
- attachment.html (text/html — 4.6 KB)