> -----Original Message-----
> From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, October 16, 2002 2:22 PM
> To: Struts Developers List; [EMAIL PROTECTED]
> Subject: Re: Tiles Refactorings for 1.1 compatability
>
>
>
>
> On Wed, 16 Oct 2002, Ted Husted wrote:
>
> > Date: Wed, 16 Oct 2002 17:13:19 -0400
> > From: Ted Husted <[EMAIL PROTECTED]>
> > Reply-To: Struts Developers List <[EMAIL PROTECTED]>,
> > [EMAIL PROTECTED]
> > To: Struts Developers List <[EMAIL PROTECTED]>
> > Subject: Re: Tiles Refactorings for 1.1 compatability
> >
> > 10/16/2002 5:01:55 PM, Eddie Bush <[EMAIL PROTECTED]> wrote:
> > >I think it's reasonable we would fix things to be
> independent now, as
> > >Martin and Craig have suggested, and then look at making modules
> > >cooperate next.
> >
> > I'm not talking about anyting to do with modules
> cooperating or not. I'm just saying that the supplemental
> > Struts configuration files (for Validator and Tiles) can be
> specified as a list, but the main struts-config
> > cannot be. In my experience, many teams just want multiple
> configuration files, period. This gives people what
> > they want (multiple configs), without giving them something
> else they might not want (Chinese walls within the
> > application).
> >
> >
>
> Don't have time to dive into the substantive technical
> details today, but
> in general I'm OK with a strategy of comma-delimited list of
> struts-config.xml resource files used to configure a single app module
> (consistent with the Tiles and Validators styles). I presume
> this just
> means running as many Digester.parse() calls as you need, and no other
> fundamental changes, right?
That's one possibility, but it leaves the door wide open for people to shoot
themselves in the foot.
Consider a situation with two config files, a.xml and b.xml. Now, a.xml
contains an action, actionA, that specifies a form bean named theBean of
type FormBeanA, and b.xml contains an action, actionB, that specifies a form
bean named theBean of type FormBeanB. If the config entry in web.xml lists
a.xml before b.xml, then actionA will fail; in the other order, actionB will
fail. An interesting one to debug...
At the very least, the config reading code would need to be modified to
throw an exception whenever a duplicate entry of any type was encountered.
That would alleviate most of the problem, but would still leave the door
open for an interesting debugging session if, for example, actionB
referenced theBean, but theBean itself was accidentally omitted from b.xml
(but still configured through a.xml).
--
Martin Cooper
>
> Craig
>
> > >Context-relative? Ok, but you have no sharing in that
> scenario. The
> > >contextRelative approach just says "interpret this as
> relative to the
> > >application root path" - I don't see how that makes sense
> here, but I'm
> > >surely missing something.
> >
> > The purpose of a Tiles Definition is utilimately to include
> tiles, which means we need to specify a path to the
> > tile. If we can mark some of the paths to be
> application-relative, then the modules can share tiles.
> >
> >
> > >think) what is desirable (what I understood you were
> after) would be to
> > >say "oh - this definition extends that one, but *that* one
> happens to be
> > >in a different module". Am I on the wrong page here? I
> know this is my
> > >goal - that's what I'm after.
> >
> > That would be cool, but it doesn't need to be in this release.
> >
> > Both the ActionMappings and the Definitions should support
> this type of extending in some future release
> > (probably 1.2+).
> >
> > -Ted.
> >
> >
> >
> >
> > --
> > 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]>
