You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Carlos Pita <ca...@gmail.com> on 2009/06/01 20:08:09 UTC
Style and variant
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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Style and variant
Posted by Igor Vaynberg <ig...@gmail.com>.
https://issues.apache.org/jira/browse/WICKET-2298
-igor
On Mon, Jun 1, 2009 at 11:45 AM, Igor Vaynberg <ig...@gmail.com> 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 <ca...@gmail.com> 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: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Style and variant
Posted by Igor Vaynberg <ig...@gmail.com>.
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 <ca...@gmail.com> 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: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org