The composable request processor has nothing to do with setting up the <action-mapping> so far as I know, and applicatoin level uses of Chain are irrelevant. So, v1.3 does not have any more of a framework level solution than does v1.2.x. No?
Jack On Thu, 17 Mar 2005 22:34:10 -0500, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: > Dakota Jack wrote: > > I think everyone has built solutions to the problem. But, the problem > > should be solved on the framework level, in my opinion. > > And I would be one to agree with that. > > But, here's the problem I think... > > 1.3 offers a framework-level solution for this. In fact, it's the core > of what 1.3 is! > > But, since we know that new features won't be added to anything prior to > 1.3, getting a solution in the framework level in the current releases > isn't an option, right? > > So, we either need (a) a non-intrusive solution that can be added as an > extension to do this or (b) come up with an agreeable pattern and > recommend people use that if they aren't using 1.3. > > Frank > > > > > 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] > >> > >> > > > > > > > > -- > Frank W. Zammetti > Founder and Chief Software Architect > Omnytex Technologies > http://www.omnytex.com > > -- "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]
