yeah, this is a problem with the design of the resource resolution. unfortunately we cannot fix until 1.5. here is an email thread where some possible future solutions were discussed.
http://markmail.org/thread/lj3luznjnvbun72r i didnt notice a jira issue for this so i will add one. -igor On Mon, Jun 1, 2009 at 11:08 AM, Carlos Pita <[email protected]> wrote: > Hi all, > > we have a site where some pages/components implement variant V. Now > there is a requirement to sell a mainly reskinned version S of this > site to a customer. So my first thought was to implement this > site-wide "variant" S as a style. But soon I realised that _V wouldn't > match variant V for site S. That is, that there is no default site for > variations of a component. So, if I had: > > MyComponent > MyComponent_V > > I'm now forced to duplicate MyComponent_V in MyComponent_S_V even if > there is no difference at all for that component in both sites (which > is the common case). > > Also, as ComponentStringResourceLoader directly instantiates > ResourceNameIterator, there is no simple hook to customise the > resolution sequence. One should reimplement > ComponentStringResourceLoader and its subclass > ClassStringResourceLoader in order to get such simple change in the > resolution algorithm. This is done mostly by copy&paste. > > I think that: > > i. style and variations are not treated very orthogonally, > MyComponent above matches both the default style and S, but > MyComponent_V matches only the default site. IMO this violates the > rule of least surprise, I would expected: MyComponent_V_S then > MyComponent_V then MyComponent_S then MyComponent. Anyway, I agree > this is arguable, because of the ambiguity between MyComponent_V and > MyComponent_S: it's not very clear which should go first. But in this > case, the impossibility to define a sequence that is good for everyone > reinforces next point (ii). > > ii. ResourceNameIterator should be configurable (that is, I expect > some ioc here). Also style and variation shouldn't be merged at one > single parameter at this point; this falls under ResourceNameIterator > responsability instead. > > What do you think? > > Kind regards > -Carlos > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
