Can someone tell me for sure whether I have an incorrect understanding or not? And let me just say that if I am in fact incorrect, wouldn't THAT be exactly what SHOULD be possible in 1.3? To me, being able to alter the basic request processing pipeline is cool (my Struts Web Services project becomes very easy then), but the thing I really saw as interesting down the road was being able to create a Chain and have it execute where I would only have a single Action in "classic" Struts.
I look forward to an answer on this...
Frank
Dakota Jack wrote:
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
-- 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]
