Rick Reumann wrote:
(ok, but this is not starting with jsp)(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 simpledesign. 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.
That not what I do!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
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 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.(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).
(Again with beans you start. I think you should do navigation first, but...)The second approach is ... I have two FormBeans - a SearchFormBean and ProjectFormBean.
(lets call is search action...)first action
Good.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
Wrong.and it is in that Search dispatch action that it simply creates a ProjectBean
Serach action does not know or care about project anything, it just forwards.
forward("Project"). The Serach bean is in scope, done!
Nope.and then calls projectBean.populate( var var var) and then puts the ProjectBean in scope.
Nope.Forward then goes to the display projects page.
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.
You are trying to shourt cut, trust me, but I am about to give up.I don't believe either approach above is a "short cut." But here is why I am beginning to favor the second approach...
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.
I hope I did not say that, forms submit back to action, else you have shpageti code.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
It?2) Most importantly, I think it keeps the Action classes more "independent" and resuable.
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.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.
-- 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