On 11-08-12 07:42 PM, Ed Burns wrote:
> 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
This line from the Seam Faces UIViewAction documentation would be a good
addition to the javadoc:
"If the value of the component'simmediateattribute istrue, the action
will be invoked during the Apply Request Values JSF lifecycle phase.
Otherwise, the action will be invoked during the Invoke Application
phase, the default behavior. The phase can be set explicitly in
thephaseattribute, which takes precedence over theimmediateattribute."
Without it, the precedence of the "immediate" and "phase" attributes is
ambiguous.
>
> 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.
I look forward to giving this implementation a spin. For starters, I'll
see if I can use it as a drop-in replacement for the Arquillian tests we
have against the existing Seam Faces viewAction component.
> 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,
To me, it seems unfortunate that we force a redirect. Do we have to
require this redirect explicitly in the specification? Can we instead
leave ourselves a way out in the future, should use-cases present
themselves that warrant an internal forward (server-side redirect)?
> 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