I think everyone has built solutions to the problem. But, the problem should be solved on the framework level, in my opinion.
Jack On Thu, 17 Mar 2005 22:19:06 -0500, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: > Rick Reumann wrote: > > First off, if you are using Struts you are always going through a > > controller, even if the basic FowardAction, so even when you say you are > > going "immediately" to another page you are still going through a > > controller. > > I could be wrong here, so feel free to educate me if so... if I return a > forward from an Action that is a typical forward that references a JSP, > the request is essentially done being handled at that point, right? > What I mean by that is that a not much else happens after that, just a > typical RequestDispatcher being used to transfer control to that page. > Looking at the 1.2.6 RequestProcessor verifies this is accurate (unless > I'm wrong!) > > By contrast, if the forward references another Action mapping, the whole > request cycle starts anew, through ActionServlet, through the > RequestProcessor, through everything that goes into the whole request > processing flow, doesn't it? That's the overhead I was talking about. > Now, I'm not willing to say this is a significant problem, but it is a > true statement I believe and will certainly have an impact on > scalability concerns (as does anything done on the server) > > In this regard, I don't believe it is accurate to say you are "always > going through a controller", indeed it seems to definitely not be the > case when forwarding directly to a JSP. :) > > > Second, the next page obviously has a form on it and that form will > > submit to an Action. So why is it such a big deal to have a setUp > > dispatch method there? And once you have that setUp method in there > > (which sets up your drop downs), it's just a matter of fowarding to this > > action and giving it the dispatch setUp parameter. > > Well, for one thing I am in the camp of folks who thinks DispatchActions > aren't a great idea, but that's really a very minor point here... I > would still consider that additional overhead to be something I'd prefer > to avoid. > > > I'm actually suprised you guys think this is such a big deal. The > > situation C that I brought up a couple posts back is much more of > > annoying problem and I thought that's what you were talking about. > > I'm not sure how big a deal I really think it is, and if I previously > said it was a big deal then I probably was making more of it than it is. > What I do agree with is that this is a typical scenario faced by > developers fairly frequently, and therefore a standard approach to it > that we all agree is good to put up as a recommendation is probably a > good idea. I agree with Jack that I don't see where there is a really > good solution in existance now. You are making the argument that the > Action chaining approach *is* actually a good one. While I don't think > it rises to the level of writing the Linux kernel in Logo, I wouldn't > agree that it is an optimal solution. :) > > > Pages submit to DispatchAction methods. Most actions have a prep method > > (setUp concept) used to set up the request (or the form) with any > > necessary items. If you need to get to page that needs something > > preped/setup then simply make sure you go through the appropriate > > DispatchAction prep method. Are there more flexible solutions out > > there? I'm sure there are. The above has been working fine for me though. > > I would suggest adding that approach to the Wiki page! If it is working > that well for you, then it is certainly a relevant addition that may > help others. > > It's probably not worth debating how one solution compares to another > because they all have their benefits and problems, but we all seem to be > agreeing that the optimal solution hasn't been put forward yet (remember > we're ignoring 1.3 and chain in this discussion). Also how big a > problem it actually is doesn't seem very important. It *is* clearly > faced by people to one degree or another, so posting various approaches > is a worthwild exercise in my opinion. > > -- > Frank W. Zammetti > Founder and Chief Software Architect > Omnytex Technologies > http://www.omnytex.com > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
