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 ="">Struts Training</a> and project recovery in North East.
Open Source <a href ="">Content Management</a>  basicPortal sofware
Best practice<a href ="">Struts Support</a> v.1.1 helper ScafflodingXPress

Reply via email to