10/18/2002 5:42:20 AM, Cedric Dumoulin <[EMAIL PROTECTED]> wrote: > If you have a strong separation between modules with Tiles, you go >against the Tiles philosophy (share to reuse, to reduce maintenance, >...). If you do strong separation, you will be consistent with the >module philosophy, but you will be inconsistent with the Tiles one. So, >peoples using Tiles will not use modules because they will loose one of >its main advantage. > So, we need a way to conciliate both philosophy. > My idea was to have one Tiles factory per module, and to have a syntax >allowing cross references between module namespaces (for URL). Also, a >same tiles config file could be used by several factories, allowing some >commons basic definitions. This later requirement bring some problems: >the shared config file namespace is not the same depending on the >loading module. In this case, how to specify URLs in a way consistent to >module philosophy ? Should we mark all as contextRelative=false ? If >yes, what will happen if the module name change ? > This is such little things that need to be solved in order to propose >a consistent behavior. After that, it will be more easy to implement >something !
I think the important thing is to be able to share the physical tiles, include the layouts, by being able to specify "contextRelative=true" when appropriate. This would let them keep all the shared files in a "common" folder (or equivalent) off the application root. In practice, I think most of the Definitions will fall along module lines, but we will still want to use a handful of base definitions that each module will extend. Since Tiles accepts a list of comma-delimited configurations, one of these could be the global definitions that the modules all extend. There will be some redundency in that each module will create its own runtime copy of the base definitions, but that sounds like small change to me. I agree with Martin in that it would be best if all the configuration files followed the same patterns. In a later release, perhaps we can get the other files extending elemenets too, at which time we can come up with a cleaner implementation for a shared configuration. But for now, if + each module could use its own attribute to store it Definitions, and + we can still specify a list of configuations for each module, and + we can specify "contextRelative=True" where appropriate (on an element-by-element +basis) I think we would be good =:0 -Ted. -- To unsubscribe, e-mail: <mailto:struts-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:struts-dev-help@;jakarta.apache.org>
