struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Cooper" <martin.coo...@tumbleweed.com>
Subject RE: Tiles Refactorings for 1.1 compatability
Date Wed, 16 Oct 2002 23:02:35 GMT


> -----Original Message-----
> From: Craig R. McClanahan [mailto:craigmcc@apache.org]
> Sent: Wednesday, October 16, 2002 3:51 PM
> To: Struts Developers List
> Subject: RE: Tiles Refactorings for 1.1 compatability
> 
> 
> 
> 
> On Wed, 16 Oct 2002, Martin Cooper wrote:
> 
> > Date: Wed, 16 Oct 2002 14:43:44 -0700
> > From: Martin Cooper <martin.cooper@tumbleweed.com>
> > Reply-To: Struts Developers List <struts-dev@jakarta.apache.org>
> > To: 'Struts Developers List' <struts-dev@jakarta.apache.org>
> > Subject: RE: Tiles Refactorings for 1.1 compatability
> >
> >
> >
> > > -----Original Message-----
> > > From: Craig R. McClanahan [mailto:craigmcc@apache.org]
> > > Sent: Wednesday, October 16, 2002 2:22 PM
> > > To: Struts Developers List; ted@husted.com
> > > 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 <husted@apache.org>
> > > > Reply-To: Struts Developers List 
> <struts-dev@jakarta.apache.org>,
> > > >      ted@husted.com
> > > > To: Struts Developers List <struts-dev@jakarta.apache.org>
> > > > Subject: Re: Tiles Refactorings for 1.1 compatability
> > > >
> > > > 10/16/2002 5:01:55 PM, Eddie Bush <ekbush@swbell.net> 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...
> >
> 
> This is semantically equivalent to declaring two actions with the same
> path in the same file, with equivalent results.

That's true. However, I think it's more likely to be a problem when there
are multiple files, especially if different people are working on those
files. A well-defined naming convention would be a necessity.

> 
> > 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).
> >
> 
> We should probably do this anyway to deal with my previous comment.

Good point.

--
Martin Cooper


> 
> > --
> > Martin Cooper
> 
> Craig
> 
> 
> --
> To unsubscribe, e-mail:   
> <mailto:struts-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: 
> <mailto:struts-dev-help@jakarta.apache.org>
> 
> 


--
To unsubscribe, e-mail:   <mailto:struts-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-dev-help@jakarta.apache.org>


Mime
View raw message