> -----Original Message-----
> From: Ted Husted [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, October 16, 2002 2:13 PM
> To: Struts Developers List
> 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).
Well, IMO, the reason Validator does this is more of a workaround than a
real solution. The issue is that Struts provides a standard set of
validation rules, but the user needs to be able to add their own application
specific rules and usage criteria.
Again IMO, a better way to solve this kind of problem is to use an 'extends'
or 'depends' mechanism to pull one set of criteria in from another.
Therefore, personally, I'd prefer not to proliferate the workaround approach
across other areas of Struts, and do it the right way instead.
--
Martin Cooper
>
>
> >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]>
