[jira] Closed: (STR-1621) [scaffold] issues with actions

["Ted Husted (JIRA)" <ji...@apache.org>]

     [ http://issues.apache.org/struts/browse/STR-1621?page=all ]

Ted Husted closed STR-1621.
---------------------------

    Resolution: Won't Fix

This code has been archived. 


> [scaffold] issues with actions
> ------------------------------
>
>                 Key: STR-1621
>                 URL: http://issues.apache.org/struts/browse/STR-1621
>             Project: Struts 1
>          Issue Type: Improvement
>          Components: Extras
>    Affects Versions: Nightly Build
>         Environment: Operating System: other
> Platform: Other
>            Reporter: Ted Husted
>         Assigned To: Ted Husted
>            Priority: Minor
>
> We are using the scaffold extension of Struts for a few months now
> and I must say that we are globallyvery happy with it.
>  
> However, after this period of intensive use, I would like to report you
> some points that could be improved:
>  
>  
> 1) BaseAction.java - execute(...) method
>     The basic skeleton of the process is:
>         ...
>         preProcess(mapping,form,request,response);
>         if (isErrors(request)) {
>             return findFailure(mapping,form,request,response);
>         }
>         executeLogic(mapping,form,request,response);
>         postProcess(mapping,form,request,response);
>         etc...
>  
> I understand the need of testing the presence of potential errors after the
> preProcess phase.
> But this comes up with some side-effect.
> Imagine this scenario:
> * I call a first (scaffold) action. 
> * The process result of the first action is negative (isErrors is true).
> Therefore the code looks for the exit "failure" 
> * Imagine now that "failure" forwards to another (scaffold) action.
> * Because of the presence of errors in request (put by the first action),
>    the second action will never executeLogic and also route to "failure".
>    => it is asif the preProcess was negative
>  
>  
> 2) Aggregate ProcessResult
> ProcessAction.java - method checkOutcome(...)
>  
>              if (result.isAggregate()) {
>                  // recurse for each ProcessResult in collection
>                 Collection collection = (Collection) result.getData();
>                 Iterator iterator = collection.iterator();
>                 while (iterator.hasNext()) {
>                     ProcessResult nextResult = (ProcessResult) iterator.next();
>                     checkOutcome(mapping,request,nextResult);
>                 }
>             } else {
>                  // call extension points for whatever is returned
>                 if (result.isData())
>                     checkData(mapping,request,result);
>                 if (result.isMessages())
>                     checkMessages(mapping,request,result);
>                 if (result.isDispatch())
>                     checkDispatch(mapping,request,result);
>             }
>  
>  
> We clearly see that a *single* ProcessResult might be data and/or messages
> and/or dispatch.
> But it is not possible to combine data *and* dispatch* for an *aggregate* result.
> (messages and dispatch info attached to the top-level result are ignored)
>  
> An immediate workaround may seem to put the dispatch in one of the (sub-)
> results of the collection.
>  
> BUT as we recurse for each result of the collection, this is the *very last* result
> that will definitively set the final value of the Tokens.SUCCESS request attribute.
>  
> protected void checkDispatch(...) {
>         ActionForward forward = null;
>         if (processResult.isDispatchPath()) {
>             forward = new ActionForward(dispatch);
>         } else {
>             forward = mapping.findForward(dispatch);
>         }
>  
>             // Our findSuccess looks for this
>         request.setAttribute(Tokens.SUCCESS,forward)
>  
> Conclusion: If a dispatch is set by a non-last item, it is no worse: it will be
> reset to null by the last one :-(

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