Re: action chaining [was] Re: major headaches:)

Rick Reumann wrote:

>(Please read my last post before this one...)
>
>On Fri, 30 May 2003 12:55:26 -0400, Vic Cekvenich wrote:
>
>  
>
>>basicPortal uses the Struts aproach, and it works for much more complex
>>situations.
>>Last time I sugested M. V. C. and you did not like, as I said maybe you
>>over design?
>>    
>>
>
>Actually, I think when you forward when Action to another Action you end
>up having to over-design and your application because much more tangled up
>and messy (and less M.V.C).. I'll show why...
>
>
>  
>
>>Try again: When looking at the problem, try allways to use a simple
>>    
>>
>design.
>
>Yes, this is what I want to do. I think forwarding my Action to another
>Action makes things "less" simple.
>
>  
>
>>    Suggestion:
>>Start with listing you forms (pages)! projectDetail.jsp
>>Each form has a an action, we call action to get to the jsp.
>>    
>>
>
>YES perfect. I agree... BUT remember all of this discussion started
>because I mentioned if I have SearchFormBean filled out you mentioned you
>should have that end up forwarding to another Action that takes care of
>the display. So following your direction I wouldn't be able to do your
>sugggestion.
>
>  
>
>>ProjectDetailAct
>>So just program navigation for now, a menu gets to this. Call action to
>>return a jsp. No thinking in MVC.
>>    
>>
>
>Right again - and this is what I agree is the Simplest (yet you're
>suggesting otherwise).
>
>
>I'll break this down as simply as possible under two approaches.
>
>The first is the approach you mentioned...
>
>I have two FormBeans - a SearchFormBean and ProjectFormBean.
>
(ok, but this is not starting with jsp)

>
>first action maps to a SearchFormBean and puts it in scope and forwards
>you to the searchForm.jsp.
>
>When you submit this form you are NOT forwarded to a JSP but are forwarded
>on a ProjectAction
>
That not what I do!
JSP submits back to its own CONTROLER. That is why its a controler, it 
decides where to go.
So SearchAct forward to JSP, JSP submits back to SearchAct, for action 
to decide where to forward to next. See if we have all the serach data 
else go back and get it, then forward.


>... now for this ProjectBean to get populated based on
>the SearchBean parameters it has to pull this SearchBean out of scope
>INSIDE of the ProjectAction and then pull out the params and then call the
>ProjectBean.populate( var, var, var) method.  
>

Ok so now we forward to projectAction. The action takes the bean out of 
scope and says
projectBean.populate(.....
OK so far

>(I'm ignoring the side
>annoying fact that if any searchForm.jsp parameters match and properties
>in ProjectBean, then ProjectBean now picks them up also).
>  
>
I have no idea what that means, and if I read it right it's wrong 
serachBean and project bean are 2 diffrent beans and have nothing to do 
with each other, they are not nested.

>
>The second approach is ...
>
>I have two FormBeans - a SearchFormBean and ProjectFormBean.
>
(Again with beans you start. I think you should do navigation first, but...)

>
>first action
>
(lets call is search action...)

> maps to a SearchFormBean and puts it in scope and forwards
>you to the searchForm.jsp.
>
>Now when searchForm.jsp submits it does not forward you to the
>ProjectAction. Instead since you are doing a search it submits to the
>SearchAction 
>
Good.

>and it is in that Search dispatch action that it simply
>creates a ProjectBean
>
Wrong.
Serach action does not know or care about project anything, it just 
forwards.
forward("Project"). The Serach bean is in scope, done!

> and then calls projectBean.populate( var var var)
>and then puts the ProjectBean in scope.
>  
>
Nope.

>Forward then goes to the display projects page.
>
Nope.
Forward goes to action, we can only call tha page via it's page controller.

So the project action gets the serach bean out of session and gets the 
properites.
It then does project.populate(x,y,z);  // you unit test beans before 
using them, else you will code slowly

Here is a tip, to get to page you call the page controller (action), and 
page submits to it's controller. This way in MVC we can find code.

>
>
>I don't believe either approach above is a "short cut." But here is why I
>am beginning to favor the second approach...
>
You are trying to shourt cut, trust me, but I am about to give up.
If you have 2 pages, you should have 2 actions and 2 beans. (MVC!) You 
try to do 5 "objects" for 2 pages.
 I can lead a horse to the water, shove the face in and ... nothing 
happens.

>
>1) It matches PERFECTLY with  your initial suggestion of how you set up
>the flow of the application. Example: you search and when you are done
>searching where should you go ... to the the displayProjects.jsp
>
I hope I did not say that, forms submit back to action, else you have 
shpageti code.  

>
>2) Most importantly, I think it keeps the Action classes more
>"independent" and resuable. 
>
It?

>For example what if later on I decide that the
>users no longer need to use the search form to get a list of projects?
>well, if I use the first approach my Action has to account for the use of
>the SearchFormBean in it (since it's being pulled out of scope to get the
>parameters). If I go with the second approach, ProjectAction doesn't need
>to be changed, since it doesnt' even concern itself with the
>SearchFormBean.
>
>3) There isn't any chance that parameters in the intial form Request will
>end up setting some parameters in the later form bean associated with the
>new Action you forward to.
>
>
>There are definitely some draw backs to this second approach though:
>
>The main one I can think of is that your first Action needs to be aware of
>where it's going and might have to set up some beans into scope. So the
>problem is later on if  you change where you want this first Action to go
>to, you end up having to fix up some of the beans you set up.  However, I
>should add that the first approach has the same problem in a sense that
>the second Action you forward to has to be aware of what is COMING IN. So
>neither solution is perfect in my opinion, but the second approach I think
>is cleaner and less problematic in the long run. 
>
>
>
>  
>
You have demonstrated that you know Struts beyond doubt! I think you are 
ready to take my advanced online class, it's cheap and you will be a 
better programer and it's lab oriented and teach many skills.


-- 
Vic Cekvenich,
Struts Instructor,
1-800-917-JAVA

Advanced <a href ="baseBeans.com">Struts Training</a> and project recovery in North East.
Open Source <a href ="baseBeans.com">Content Management</a>  basicPortal sofware
Best practice<a href ="baseBeans.com">Struts Support</a> v.1.1 helper ScafflodingXPress