>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. 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]>
