SECTION: Email Thread Catchup
LU> "... sequential execution of the actions ..." sounds suspicious. In
LU> practice, in previous JSF versions that use case is not considered.
LU> Usually there is only one action per request, but in this case I don't
LU> see how can be possible multiple actions, because at the end only one
LU> navigation will take effect.
EB> The current implementation will call
EB> NavigationHandler.handleNavigation() for each action in the order in
EB> which they appear in the view. The last one wins.
In practice, I have found it more useful to have it be the case that the
first action that causes the UIViewRoot to be changed wins.
DA> Now, we could solve #2 a couple different ways.
DA> Alt #1: We could imply a redirect for any navigation rule matched by
DA> a view action. That would certainly solve our problem of having to
DA> manually manipulate the lifecycle. The only downside to this
DA> approach is that the developer may intend to have an internal
DA> forward (server-side redirect) so as to cloak the URL in the
DA> navigation bar. I don't know how important of a requirement that
EB> is.
EB> I think we should go with this option. The <f:viewAction> usage
EB> contract must clearly state that a redirect will occur if a match
EB> occurs.
LU> Sounds good, after all that's similar to a button click. In theory, to
LU> check this a call to navigationHandler.getNavigationCase() and then a
LU> check to isRedirect() will do the job.
EB> Good point. Nice that we are using ConfigurableNavigationHandler in the
EB> spec itself now.
In practice, I have found it practical to make it so a UIViewAction
navigation is always treated as a redirect.
EB> Here are the conclusions from this message.
EB>
EB> 1. Continue to do the "wrap the FacesContext to make renderResponse a
EB> no-op before calling ActionListener.processAction()" thing.
Done
EB> 2. Clearly state that a redirect must happen in the event of a
EB> navigation rule match.
Done
EB> 3. Rename "if" attribute to "rendered".
Done.
EB> 4. Allow ActionListener children.
This doesn't require any spec work, but it's not implemented yet.
Please see <
http://java.net/jira/browse/JAVASERVERFACES-2165> to track
the implementation of this feature.
SECTION: Resolution Attempt One Realization
Thanks to Oracle's contract with Sonatype (w00t for them) I can now
publish artifacts to a proper nexus repo. This allows us to look
directly at the javadoc jars, such as this link to the javadoc for
UIViewAction. Unfortunately, I haven't figure out how to make the build
system include all the other stuff I want in the javadoc jar, such as
the color coded changebars. That'll have to come later.
ACTION: Please review the javadocs for this class.
https://maven.java.net/service/local/repositories/snapshots/archive/javax/faces/javax.faces-api/2.2-SNAPSHOT/javax.faces-api-2.2-20110813.023226-2-javadoc.jar/!/javax/faces/component/UIViewAction.html
Likewise, here is the source.
https://maven.java.net/service/local/repositories/snapshots/archive/javax/faces/javax.faces-api/2.2-SNAPSHOT/javax.faces-api-2.2-20110813.023226-2-sources.jar/!/javax/faces/component/UIViewAction.java
ACTION: I particularly want Brian Leatham's review on this.
ACTION: Please review the spec language for the changes to
NavigationHandler that will be in the PDF:
M applicationIntegration.fm
* 7.4.2 Rewrite the paragraph on how to handle a redirect as follows.
If a matching <navigation-case> element was located, and the
<redirect/> element was specified in this <navigation-case>
+ or a call to UIViewAction.isProcessingBroadcast() returns true,
call getRedirectURL() on the ViewHandler, passing the current
FacesContext, the <to-view-id>, any name=value parameter pairs
specified within <view-param> elements within the <redirect> element,
and the value of the include-view-params attribute of the <redirect />
element if present, false, if not. The return from this method is the
value to be sent to the client to which the redirect will occurr. Call
getFlash().setRedirect(true) on the current FacesContext. Cause the
current response to perform an HTTP redirect to this path.
+ If the preceding call to UIViewAction.isProcessingBroadcast() had
+ returned true, also call setKeepMessages(true) on the flash.
Call responseComplete() on the FacesContext instance for the current
request. If the content of <to-view-id> is a value expression, first
evaluate it to obtain the value of the view id.
The jars may be obtained directly from here.
https://maven.java.net/content/repositories/snapshots/javax/faces/javax.faces-api/2.2-SNAPSHOT/
Ed
--
| edward.burns_at_oracle.com | office: +1 407 458 0017
| homepage: | http://ridingthecrest.com/
| 30 business days until JSF 2.2 Early Draft Review