(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. 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... 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. (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). The second approach is ... I have two FormBeans - a SearchFormBean and ProjectFormBean. first 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 and it is in that Search dispatch action that it simply creates a ProjectBean and then calls projectBean.populate( var var var) and then puts the ProjectBean in scope. Forward then goes to the display projects page. I don't believe either approach above is a "short cut." But here is why I am beginning to favor the second approach... 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 2) Most importantly, I think it keeps the Action classes more "independent" and resuable. 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. -- Rick _______________________________________________ MVC-Programmers mailing list [EMAIL PROTECTED] http://www.basebeans.net:8080/mailman/listinfo/mvc-programmers
