I agree with David that it's more coherent and pratical to put all the pieces of a module under the same root. When I tryed to patch this problem I first thought to turn ActionConfig.forward and ActionConfig.input into ForwardConfig rather than String, but I don't master Struts enought to do it so I patched it more trivialy waiting for your advice.
I'm just the reporter but I think that if you don't patch it at all, forwardPattern is useless. I can't figure out how one can use it... or what ? Putting the resources pointed by input and forward in another place than ForwardConfigs ? No interest... So if you absolutly whant to relase 1.1, frankly remove forwardPattern and pagePattern features until you think more about it and let the default $M$P which works. Malik. Sunday, February 09, 2003 3:39 AM , David Graham <[EMAIL PROTECTED]> a écrit : > My understanding of modules is that they're independent pieces that > can plug into any Struts app. They can point to external resources > if they want but don't need to. Based on that, I believe all > resources for a module should live in the same module root directory. > You shouldn't have some jsps under WEB-INF, actions somewhere else, > etc. So, you should be able to use the <controller> forwardPattern > attribute to point to each module's root directory. > > Any place that you say "module relative" should not assume $M$P but > the full module root directory. I believe that includes *all* of the > scenarios described. I don't understand why we would discriminate on > the forwarding implementation based on what kind of thing you're > forwarding to. IMHO, it doesn't matter, every kind of resource > belongs to the module. > > +1 on doing this in 1.2 > > David > > > > > From: "Craig R. McClanahan" <[EMAIL PROTECTED]> > > Reply-To: "Struts Developers List" <[EMAIL PROTECTED]> > > To: [EMAIL PROTECTED] > > CC: [EMAIL PROTECTED] > > Subject: [Bugzilla #16603] Discussion Please > > Date: Sat, 8 Feb 2003 15:23:23 -0800 (PST) > > > > OK, I've assigned myself the following bugzilla ticket: > > > > http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16603 > > > > and am trying to decide how to deal with it. I think I understand > > what the reporter (cc'd above) is proposing. What's not clear is > > whether we should make any change now, or perhaps ever. I'd like > > to discuss that here before deciding. > > > > > > Background: > > ---------- > > > > For a while now, we have supported the "forwardPattern" and > > "pagePattern" properties on the ControllerConfig object. These > > patterns support certain substitutions so that you can, for > > example, declare that you want your JSP pages under /WEB-INF so > > that they can be accessible only via RequestDispatcher.forward() > > calls. > > > > Example scenario (assume a module prefix of "/mymodule"): > > > > <global-forwards> > > ... > > <forward name="Main Menu" path="/mainmenu.jsp" > > contextRelative="false"/> > > ... > > </global-forwards> > > > > <controller ... forwardPattern="/WEB-INF/pages$M$P" .../> > > > > If an Action returns the "Main Menu" ActionForward (nee > > ForwardConfig) object, the request procesor will ultimately call > > RequestUtils.forwardURL() to calculate the context-relative path > > of "/WEB-INF/pages/mymodule/mainmenu.jsp". If no forward pattern > > had been specified, the default mechanism would have returned > > "/mymodule/mainmenu.jsp" instead. > > > > So far, so good. Now we've got a way to "globally redirect" the > > URLs within a module, without having to modify all of the > > individual paths in our forward directives. > > > > The problem pointed out by the Bugzilla ticket, though, is that we > > do not respect forwardPattern universally; it is *only* used in the > > scenario described above, plus in a couple of other special cases. > > > > > > Other Potential Remapping Scenarios: > > ----------------------------------- > > > > Scanning the code for the core Struts controller (I didn't check > > the Tiles request processor, but suspect it might have similar > > issues), there are several other scenarios where one might argue > > that the remapping through the specified forwardPattern would make > > sense. The ones I found are as follows, numbered for reference in > > later discussion: > > > > (1) <action ... forward="/foo" .../> > > > > Tells request processor to handle this request by performing > > a RequestDispatcher.forward() to the specified "module-relative > > path of the servlet or other resource that will process this > > request", instead of invoking an Action. This path is not > > currently processed by any specified "forwardPattern", instead > > a pattern of "$M$P" is assumed. > > > > (2) <action ... include="/foo" .../> > > > > Tells request processor to handle this request by performing > > a RequestDispatcher.include() to the specified "module-relative > > path of the servlet or other resource that will process this > > request", instead of invoking an Action. This path is not > > currently processed by any specified "forwardPattern", instead > > a pattern of "$M$P" is assumed. > > > > (3) <action ... input="/foo" .../> > > > > There are actually two subcases here, depending on the state of > > the "inputForward" property of our module's ControllerConfig: > > > > (3a) <controller ... inputForward="true" .../> > > > > The value of the "input" property is treated as the name > > of a local or global ForwardConfig, which is then processed > > through the forwardPattern remapping just like an > > ActionForward returned from an Action would be. > > > > (3b) <controller ... inputForward="false" .../> > > > > The value of the "input" property is treated as the > > "module-relative path of the action or other resource > > to which control should be returned if the form bean > > returns validation errors. This path is not currently > > processed by any specified "forwardPattern", instead a > > pattern of "$M$P" is assumed. > > > > Note that 3b is the default for backwards compatibility: > > > > (4) <action ... path="/foo" .../> > > > > This is the module-relative path that is used to match a > > request to a particular action. It is not currently mapped > > through any specified "forwardPattern", instead a pattern of > > "$M$P" is assumed. > > > > (5) <exception ... path="/foo" .../> > > > > This is the module-relative path of the resource that should > > complete this request/response if an Action throws an exception > > of the specified type. Whether remapping occurs or not is up to > > the ExceptionHandler that is invoked; the default implementation > > constructs an ActionForward based on this path (but sets the > > contextRelative property, which looks like a bug but isn't > > related to the issue at hand here), which will get processed > > through the "forwardPattern" remapping if we fixed the > > contextRelative bug. > > > > So, we currently do the remapping in case (3b), and ought to be > > doing it in case (5). But what about the other scenarios? > > > > > > Analysis: > > -------- > > > > The underlying issue is that we have fallen into the (bad, but > > that's hindsight for you) habit of using ActionForward instances to > > point at (at least) three very different kinds of things: > > > > (a) The view tier component that should actually render > > the response (typically a JSP page) > > > > (b) The next action to execute, if you are doing action > > chaining > > > > (c) The "application resource" that should handle a thrown > > exception from an action (which could be a view tier > > component, an arbitrary servlet, or an action) > > > > The original intent of "forwardPattern" was to cover case (a) only, > > because it was (in theory) only the view tier components that you'd > > want to redirect for (i.e. to put JSP pages under /WEB-INF, or > > otherwise remap the set of view components for a particular > > module). Case (b) seems like it should NOT be mapped, for > > consistency with how case (4) is handled (mapping the original > > request to the original action in the first place). Case (c) should > > probably be remapped if it's a view component, but not if it's an > > action. > > > > But there is nothing about an ActionForward that lets you > > unambiguously determine whether it points at a view component or > > not. :-( > > > > > > Recommendation: > > -------------- > > > > If we were not imminently trying to release a 1.1 final, I would be > > tempted to design and work out a strategy for dealing with this > > ambiguity problem, and hash out what the right behavior should be > > in each case. However, at this point in time, I'm going to suggest > > that we resolve this one as LATER and put it into the "1.2 Family" > > camp. We're going to need to deal with it in a 1.2 time frame > > anyway, especially if we try to implement any sort of "module > > configuration inheritance" mechanisms, which are only going to make > > the problem worse. > > > > In a 2.0 time frame, the lesson I draw from this is that we will > > want to be very specific in defining how mapping of logical paths > > to physical paths is performed, including a way to distinguish what > > kind of logical path you're talking about (so that you can apply > > different rules for view components and for action components, for > > example). > > > > Does this sound like a plan that we (committers) can agree to? > > > > Craig > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > _________________________________________________________________ > MSN 8 with e-mail virus protection service: 2 months FREE* > http://join.msn.com/?page=features/virus > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
