> -----Original Message-----
> From: Ted Husted [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, October 16, 2002 11:23 AM
> To: Struts Developers List
> Subject: Re: Tiles Refactorings for 1.1 compatability
>
>
> From an API perspective, a big issue may be being able to
> also refer to tile locations using both module-
> relative AND application-relative URIs. In a large
> application, we will want to share tiles between modules to
> establish a common look and feel.
>
> I have a beast in front of me now with 8 logical application
> "segments" that could become modules in 1.1. But,
> there is only one library of tiles, which they all happily
> share. Each module has its own set of pages, but
> being the same application, these pages all use the same
> layouts and tiles. I could use a separate tiles-def.xml
> for each but we need to also be able to share tiles and
> layouts somehow.
>
> In practice, all a lot of teams really want is multiple
> configuration files. Right now, the modules seem to be
> doing double-duty. You can subdivide a large application into
> modules to gain multiple configurations, but there
> is a corresponding gain in complication unless the modules
> are very loosely coupled. (The sharing world-view.)
>
> Now that we have modules in play, would anyone VETO adding
> the capability to have a delimited list of struts-
> configs (for each module) -- to match what we do with the
> tiles and validator configurations? If for no other
> reason, than because we should be providing a consistent
> approach across components.
Would I veto adding new functionality in a second beta that everyone is
waiting for a final release of? I'd have to seriously consider it.
--
Martin Cooper
>
> Then, if there is something in the module implementation that
> classes with a team's world-view, they can
> simulate modules usng multiple configuration files. They
> would end up embedding the module directory in the
> URIs, but some people might consider that a fair trade-off to
> the sharing issues.
>
> -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]>
