You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by "Martin Marinschek (JIRA)" <de...@myfaces.apache.org> on 2006/09/21 01:02:23 UTC

[jira] Commented: (MYFACES-1411) Lifecycle phase executions repetitions

    [ http://issues.apache.org/jira/browse/MYFACES-1411?page=comments#action_12436390 ] 
            
Martin Marinschek commented on MYFACES-1411:
--------------------------------------------

He's already faxed in an ICLA - it hasn't been processed so far, but it will surely be done before the next release, I suppose.

By the way - Nikolay started his own JSF-implementation, called IFaces on sourceforge. Everything he's doing there is under ASL as well. I could convince him that he'd try it with us a little, and that he gives us a little help where MyFaces needs polishing.

Let's keep the issue opened until we see his ICLA has been processed.

regards,

Martin

> Lifecycle phase executions repetitions
> --------------------------------------
>
>                 Key: MYFACES-1411
>                 URL: http://issues.apache.org/jira/browse/MYFACES-1411
>             Project: MyFaces Core
>          Issue Type: Improvement
>          Components: JSR-127
>    Affects Versions: 1.1.4
>            Reporter: Nikolay Petrov
>         Assigned To: Martin Marinschek
>             Fix For: 1.1.5-SNAPSHOT
>
>         Attachments: ApplyRequestValuesExecutor.java, InvokeApplicationExecutor.java, LifecycleImpl.java, PhaseExecutor.java, ProcessValidationsExecutor.java, RenderResponseExecutor.java, RestoreViewExecutor.java, UpdateModelValuesExecutor.java
>
>
> Every phase in LifecycleImpl looks like:
>     private boolean applyRequestValues(FacesContext facesContext, PhaseListenerManager phaseListenerMgr)
>         throws FacesException
>     {
>     		boolean skipFurtherProcessing = false;
>         if (log.isTraceEnabled()) log.trace("entering applyRequestValues in " + LifecycleImpl.class.getName());
>         try {
>             phaseListenerMgr.informPhaseListenersBefore(PhaseId.APPLY_REQUEST_VALUES);
>             if(isResponseComplete(facesContext, "applyRequestValues", true))
>             {
>                             // have to return right away
>                             return true;
>             }
>             if(shouldRenderResponse(facesContext, "applyRequestValues", true))
>             {
>                             skipFurtherProcessing = true;
>             }
>             facesContext.getViewRoot().processDecodes(facesContext);
>         } finally {
>             phaseListenerMgr.informPhaseListenersAfter(PhaseId.APPLY_REQUEST_VALUES);
>         }
>         if (isResponseComplete(facesContext, "applyRequestValues", false)
> 				|| shouldRenderResponse(facesContext, "applyRequestValues", false))
>         {
>         		// since this phase is completed we don't need to return right away even if the response is completed
>         		skipFurtherProcessing = true;
>         }
>         if (!skipFurtherProcessing && log.isTraceEnabled())
> 			log.trace("exiting applyRequestValues in "
> 					+ LifecycleImpl.class.getName());
>         return skipFurtherProcessing;
>     }
> And that is repeated as many times as phases are. The fix will be to extract the common behavior in a method, that receives one additional parameter - PhaseExecutor and delegate to it the real execution.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira