+1 by a non committee on M.C. vetoing new features. Can you wait till 1.2 Ted? .V
Martin Cooper wrote: > >>-----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]>
