> -----Original Message-----
> From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
> Sent: Monday, July 01, 2002 3:09 PM
> To: Struts Developers List
> Subject: RE: Subapps and /WEB-INF (was: Re: DO NOT REPLY [Bug 10268] -
> Sub -apps need context-relative option for 'input' of an Action)
>
>
>
>
> On Mon, 1 Jul 2002, Martin Cooper wrote:
>
> > Date: Mon, 1 Jul 2002 14:03:23 -0700
> > From: Martin Cooper <[EMAIL PROTECTED]>
> > Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> > To: 'Struts Developers List' <[EMAIL PROTECTED]>
> > Subject: RE: Subapps and /WEB-INF (was: Re: DO NOT REPLY
> [Bug 10268] -
> > Sub -apps need context-relative option for 'input' of an Action)
> >
> > I definitely like the idea of a forward attribute on
> actions. Not only is it
> > more flexible than just a path, but it also means that, in
> most cases, the
> > path itself will exist only once in the config file,
> instead of twice or
> > more. Once is more maintainable.
> >
> > I'm not so sure about the second change. It means that, for
> people who want
> > to put their JSP files under WEB-INF, we're dictating the directory
> > structure they have to use, at least at the top level. That
> may be OK for
> > some folks, but probably not for everyone.
>
> Well, we already are for subapps, by mandating that you use the subapp
> prefix as the top-level directory name (within the webapp).
> This is the
> rule that prevents you from having the JSP pages for a subapp under
> WEB-INF at all in the current scenario.
Doh! I forgot about that, because I overrode the config-locating stuff in my
app. (My config files live under
/WEB-INF/modules/module1/config/struts-config.xml. This way, I can
install/uninstall modules without having to modify the web.xml file.)
> >
> > In my particular case, the path to my JSP files looks like this:
> >
> > /WEB-INF/modules/module1/pages/foo.jsp
> >
> > (I'm using the term 'module' instead of 'sub-app' here.)
> >
> > That is, I have a directory under WEB-INF named 'modules',
> and every direct
> > descendant of 'modules' is a module directory. This has all sorts of
> > advantages for my app, but I won't go into that here.
> >
> > One idea (that is perhaps even more kludgey :) would be to
> use some kind of
> > token in the path that computeURL could substitute for, if
> it's present (and
> > perhaps only if WEB-INF is found in the path). For example,
> the path I
> > listed earlier might show up in the config file as:
> >
> > /WEB-INF/modules/$MODULE$/pages/foo.jsp
> >
> > and computeURL would replace '$MODULE$' with 'module1'.
> >
>
> We could do this with pattern matching and substitution in a fairly
> general way -- the question is whether the pattern is global
> to a subapp
> (i.e. declare it on the <global-forwards> element), local to
> a <forward>,
> or perhaps both.
>
> So, you might end up with something like this (if you liked Martin's
> pattern described above):
>
> <global-forwards pattern="/WEB-INF/modules$PREFIX$/pages$PATH$">
> ...
> </global-forwards>
>
> where $PREFIX$ gets replaced by the subapp prefix (possibly
> zero length)
> and $PATH$ gets replaced by the value of the "path" attribute. The
> default pattern (consistent with 1.1-b1 behavior) would simply be
> "$PREFIX$$PATH$".
>
> Does that make sense?
Yep, it does. I don't see a need for different patterns on a per-forward
basis, so I think per-subapp would make the most sense.
Making the pattern an attribute of <global-forwards> makes it a little less
obvious that it also applies to local forwards. However, I don't see a
better place for it, so that's fine.
Should the pattern apply only to the interpretation of paths in a <forward>,
or also to the 'input' attribute of an <action>? My vote would be for the
former, because if we're adding the 'forward' attribute to <action>, you can
always use that if you want the pattern applied.
(Now I'll have to figure out how to slot in a non-empty prefix for the
default sub-app, but that's my problem, not Struts'. :)
--
Martin Cooper
>
> > --
> > Martin Cooper
> >
>
> Craig
>
>
> >
> > > -----Original Message-----
> > > From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
> > > Sent: Monday, July 01, 2002 12:11 PM
> > > To: Struts Developers List
> > > Subject: Subapps and /WEB-INF (was: Re: DO NOT REPLY [Bug 10268] -
> > > Sub-apps need context-relative option for 'input' of an Action)
> > >
> > >
> > > Martin raises some interesting issues in this enhancement
> > > request that I'd
> > > like to discuss a little before we figure out what to do.
> > >
> > > The simplest issue is a design faux pas in the original
> struts-config
> > > setup -- the "input" parameter really should have been
> the name of a
> > > corresponding forward, so that we could auto-calculate the
> > > actual URL more
> > > gracefully. We can't change the past, but it wouldn't be
> > > hard to add an
> > > additional "forward" attribute as an alternative to "input",
> > > that works
> > > this way. What do you think?
> > >
> > > The more important issue Martin raises is that the algorithm for
> > > sub-application mapping (context-relative prefix) doesn't
> > > play very nice
> > > with folks who want to put their JSP pages in the /WEB-INF
> > > subdirectory.
> > > One way to get around this would be to modify the algorithm
> > > for converting
> > > a subapp-relative path into an absolute path in
> > > RequestUtils.computeURL().
> > > Instead of always sticking the subapp prefix before the
> > > specified path,
> > > it would look at the subapp-relative path and, if it started with
> > > "/WEB-INF" and perform the appropriate surgery. Thus, a
> > > forward to the
> > > subapp relative page "/WEB-INF/foo.jsp" in subapp "/mysubapp"
> > > would end up
> > > creating the URL:
> > >
> > > /WEB-INF/mysubapp/foo.jsp
> > >
> > > instead of the current:
> > >
> > > /mysubapp/WEB-INF/foo.jsp
> > >
> > > While this is sort of a kludge (and the whole algorithm is
> > > something that
> > > should be more easily pluggable in a post-1.1 design), it
> > > *is* backwards
> > > compatible with current usage without subapps (i.e. the path
> > > of a page for
> > > the default subapp is the same as it is now).
> > >
> > > What do you think about implementing both of these options
> > > (new "forward"
> > > option on <action>, and the calculation change)? Together, I
> > > think they
> > > address what Martin is after, and deals with the more general
> > > problems of
> > > using subapps together with /WEB-INF.
> > >
> > > Craig
> > >
> > >
> > > On 1 Jul 2002 [EMAIL PROTECTED] wrote:
> > >
> > > > Date: 1 Jul 2002 18:10:02 -0000
> > > > From: [EMAIL PROTECTED]
> > > > Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> > > > To: [EMAIL PROTECTED]
> > > > Subject: DO NOT REPLY [Bug 10268] - Sub-apps need
> > > context-relative
> > > > option for 'input' of an Action
> > > >
> > > > DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
> > > > RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
> > > > <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10268>.
> > > > ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
> > > > INSERTED IN THE BUG DATABASE.
> > > >
> > > > http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10268
> > > >
> > > > Sub-apps need context-relative option for 'input' of an Action
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > ------- Additional Comments From [EMAIL PROTECTED]
> > > 2002-07-01 18:10 -------
> > > > The problem is, my JSP pages are under WEB-INF, and the
> > > computed URL messes up
> > > > the path to that directory. If my action config looks like this:
> > > >
> > > > <action ... input='/WEB-INF/pages/myPage.jsp' ... />
> > > >
> > > > then the computed URL looks like this:
> > > >
> > > > /myApp/mySubApp/WEB-INF/pages/myPage.jsp
> > > >
> > > > which is incorrect - the sub-app name should not be there.
> > > It needs to be:
> > > >
> > > > /myApp/WEB-INF/pages/myPage.jsp
> > > >
> > > > to work correctly.
> > > >
> > > > There was also a thread on struts-user a while ago where
> > > someone else was
> > > > having a similar problem:
> > > >
> > > >
> http://marc.theaimsgroup.com/?l=struts-user&m=101865931500963&w=2
> > > >
> > > > --
> > > > To unsubscribe, e-mail:
> > <mailto:[EMAIL PROTECTED]>
> > > For additional commands, e-mail:
> > <mailto:[EMAIL PROTECTED]>
> > >
> > >
> >
> >
> > --
> > To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> > For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> > For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
> >
> >
>
>
> --
> To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
