Hi Eddie,
Eddie Bush wrote:
Cedric,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.
I wasn't trying to step on toes :-) I can't say how much more I'd prefer you refactor Tiles than me. You (obviously) are a *lot* more familiar with it's inner workings!
The point to keep in mind though is that 1.1 *is* about seperatism.
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 !
The Tiles goal of sharing common pages should be maintained in 1.1. The module goal is to let separate teams work independently on different modules. In this context, Tiles should combine both goals.
Would it, in your opinion, require undoing changes made in 1.1 to enforce seperatism to achieve a better affect in 1.2? I like your intent, I believe, very much. 1.2 is really the target for making modules work "together" though - that should be it's primary focus.
Your help is welcome. Also, someone else than me with a very well understanding of the Tiles philosophy and its current implementation is more than welcome. But, please, don't forget to expose your intention to other commiters before making heavy changes. The best is to describe your goals, your expected behavior, and maybe a simple example of use. Only after that you can propose an implementation.
If you're working on resolving this I'll just bow out and let you have it :-) Please let me know. I'm still reviewing the code to make absolutely sure I know what I'm doing before I go to changing anything, and I'd hate to be throwing wasted time into the effort - especially when a much more competent person is at hand.
Cedric
--
To unsubscribe, e-mail: <mailto:struts-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-dev-help@;jakarta.apache.org>
