https://issues.apache.org/jira/browse/WICKET-2298
-igor On Mon, Jun 1, 2009 at 11:45 AM, Igor Vaynberg <[email protected]> wrote: > 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]
