You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by "Craig R. McClanahan" <cr...@apache.org> on 2002/04/01 18:39:40 UTC
Re: Multi Struts Config files and path context wish
On Sat, 30 Mar 2002, Struts-dev Newsgroup wrote:
> Date: Sat, 30 Mar 2002 21:10:01 -0800
> From: Struts-dev Newsgroup <st...@basebeans.com>
> Reply-To: Struts Developers List <st...@jakarta.apache.org>
> To: struts-dev@jakarta.apache.org
> Subject: Multi Struts Config files and path context wish
>
> Subject: Multi Struts Config files and path context wish
> From: Vic Cekvenich <vi...@basebeans.com>
> ===
> Tiles can do multi confi like this, via CSV:
> <init-param>
> <param-name>definitions-config</param-name>
> <param-value>/WEB-INF/tiles-defs.xml,/WEB-INF/tiles-tests-defs.xml,/WEB-INF/tiles-tutorial-defs.xml,
> /WEB-INF/tiles-examples-defs.xml</param-value>
> </init-param>
> Validator does it like this, multi item:
> <plug-in className="org.apache.struts.validator.ValidatorPlugIn">
> <set-property property="pathname" value="/WEB-INF/validator-rules.xml"/>
> <set-property property="pathname" value="/WEB-INF/validation.xml"/>
> </plug-in>
>
This is actually getting changed as we speak -- it depends on *very*
non-inuitive behavior of the setPathname() method. In a standard
JavaBean, calling setPathname() will always replace the previous value --
this technique would only work if it added each value to a list. If
that's the behavior you want, the method should be addPathname() or
something instead.
> But to have multi config on Struts-config.xml we will require a path?
> The reason I do not want a path is that on a project, it is sometimes
> hard to spearate who is working on what module like that.
> Also, path in url might not be sectioned like that.
> I like how validator and tiles do it a bit better.
>
For multi-app support, I'm going to start with the assumption that we want
to use a path prefix to distinguish the sub-applications (that's the way
many other frameworks do it, it's consistent with how servlet containers
deal with webapps, ...). Given that, we have to communicate two pieces of
information to the controller servlet for each subapp:
- The path prefix for that subapp
- The struts-config.xml file to be used.
The current technique embeds the path prefix in the name of the servlet
initialization parameter, and therefore means it is *not* stored inside
the struts-config.xml file for that subapp. In this way, you can design a
subapp without knowing or caring ahead of time what the path prefix will
be (again, this is consistent with webapp design, where you don't have to
know what the context path will be).
Going to a comma-delimited list of struts-config files gives up this
ability to keep the config files independent of the path - therefore I
don't particularly care for that approach here.
> my 2 c.
> Vic
>
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Multi Struts Config files and path context wish
Posted by David Winterfeldt <dw...@yahoo.com>.
--- "Craig R. McClanahan" <cr...@apache.org> wrote:
>
>
> On Sat, 30 Mar 2002, Struts-dev Newsgroup wrote:
>
> > Date: Sat, 30 Mar 2002 21:10:01 -0800
> > From: Struts-dev Newsgroup
> <st...@basebeans.com>
> > Reply-To: Struts Developers List
> <st...@jakarta.apache.org>
> > To: struts-dev@jakarta.apache.org
> > Subject: Multi Struts Config files and path
> context wish
> >
> > Subject: Multi Struts Config files and path
> context wish
> > From: Vic Cekvenich <vi...@basebeans.com>
> > ===
> > Tiles can do multi confi like this, via CSV:
> > <init-param>
> > <param-name>definitions-config</param-name>
> >
>
<param-value>/WEB-INF/tiles-defs.xml,/WEB-INF/tiles-tests-defs.xml,/WEB-INF/tiles-tutorial-defs.xml,
> >
> /WEB-INF/tiles-examples-defs.xml</param-value>
> > </init-param>
> > Validator does it like this, multi item:
> > <plug-in
>
className="org.apache.struts.validator.ValidatorPlugIn">
> > <set-property property="pathname"
> value="/WEB-INF/validator-rules.xml"/>
> > <set-property property="pathname"
> value="/WEB-INF/validation.xml"/>
> > </plug-in>
> >
>
> This is actually getting changed as we speak -- it
> depends on *very*
> non-inuitive behavior of the setPathname() method.
> In a standard
> JavaBean, calling setPathname() will always replace
> the previous value --
> this technique would only work if it added each
> value to a list. If
> that's the behavior you want, the method should be
> addPathname() or
> something instead.
Fixed as of the nightly build from last night.
<plug-in
className="org.apache.struts.validator.ValidatorPlugIn">
<set-property property="pathnames"
value="/WEB-INF/validator-rules.xml,/WEB-INF/validation.xml"/>
</plug-in>
I wanted an addPathname(), but it cause problems with
BeanUtils. I assume if I made a PropertyDescriptor it
could deal with it.
David
>
> > But to have multi config on Struts-config.xml we
> will require a path?
> > The reason I do not want a path is that on a
> project, it is sometimes
> > hard to spearate who is working on what module
> like that.
> > Also, path in url might not be sectioned like
> that.
> > I like how validator and tiles do it a bit better.
> >
>
> For multi-app support, I'm going to start with the
> assumption that we want
> to use a path prefix to distinguish the
> sub-applications (that's the way
> many other frameworks do it, it's consistent with
> how servlet containers
> deal with webapps, ...). Given that, we have to
> communicate two pieces of
> information to the controller servlet for each
> subapp:
> - The path prefix for that subapp
> - The struts-config.xml file to be used.
>
> The current technique embeds the path prefix in the
> name of the servlet
> initialization parameter, and therefore means it is
> *not* stored inside
> the struts-config.xml file for that subapp. In this
> way, you can design a
> subapp without knowing or caring ahead of time what
> the path prefix will
> be (again, this is consistent with webapp design,
> where you don't have to
> know what the context path will be).
>
> Going to a comma-delimited list of struts-config
> files gives up this
> ability to keep the config files independent of the
> path - therefore I
> don't particularly care for that approach here.
>
> > my 2 c.
> > Vic
> >
>
> Craig
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
__________________________________________________
Do You Yahoo!?
Yahoo! Greetings - send holiday greetings for Easter, Passover
http://greetings.yahoo.com/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>