Ted Husted wrote: >>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. > Yes - saw that coming. I want to share too, but is it appropriate to do so now and skip the "seperatism" phase? If each module is, in fact, it's own little world, then that should apply to everything. This goes along with previous arguments I've voiced and been told "post 1.1" on. Would it be best to, as I suggested, have Tiles be "stupid" this release (no "chaining"/sharing), and then refactor for sharing once we have a better idea of how sub-apps will be used?
>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. > :-/ Well, there's nothing to stop you from referencing the same physical pages that I can think of - but the definitions would be duplicated I suppose. This could be solved by the same concatenation tricks used for previous versions of Struts. I know it's not ideal - but I don't think 1.1F *is* going to be (IMHO - because of the way I feel they should be implemented) ideal. 1.1.1 or 1.2 - that's where we'll whip it into shape. Is this not the direction we are headed? If not, I'd like to know now. >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. > Yeah - maybe so. You know (I think) where I stand on the duplication. I don't like it either. The idea I've had impressed upon me (by both Martin and Craig, I believe) is that we should implement 1.1 with each module being in it's "own little world" - and then follow up with discussions on how we can make them work more ideally. That is the exact impression guiding what I am doing to "fix" things that are "not 1.1 compliant". No matter what we do in the future, we need to have each module not being trampled on by the others, so refactoring to allow each app the ability to use a plugin without affecting the others is (I think) a necessary step. Whether we go one further and implement chaining is an option I would certainly be open to, but I was under the impression this shouldn't be done until "later" (post 1.1). I hope others will share their feelings. Bear in mind there are folks looking heavily at 1.1 that can't use it because of it's "beta" status. It's a time/feature trade-off :-) I don't see it being necessary to rework the config instantiation/acquisition beyond 1.1. The thing that will have to change is how the lookups are done. I really think we can break these out into two releases without having to do rework, if that is the way it needs to go. We could go ahead and refactor the lookups now too, if that's the appropriate course, but there's obviously going to be additional delay for doing so. Do we need a proposal maybe? >-Ted. > -- Eddie Bush -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
