You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Thibault Kruse <ti...@googlemail.com> on 2014/09/03 12:09:14 UTC
Variant Change Behavior
Hi,
playing around with Variants for Components, I am wondering whether
there is an elegant way to steer Variant markup loading via a
Behavior.
In our case we want to use a different markup layout based on the
width of the container the component is going to be used in, visually.
So if we imagine a Browser window with desktop size, we might want to
use a component on the full width, on a third of the width, or a
quarter of the width.
For each such container width, we need different responsive design
markup. Since this may affect many of our components which inherit
from different wicket components, I'd like to just add another html
markup file for the variant, and add a Behavior to the component that
decides the Variant.
cheers,
Thibault
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Variant Change Behavior
Posted by Thibault Kruse <ti...@googlemail.com>.
The API looks good. I don't have time to test it right now.
On Tue, Sep 9, 2014 at 9:44 AM, Martin Grigorov <mg...@apache.org> wrote:
> https://git-wip-us.apache.org/repos/asf?p=wicket.git;a=commit;h=702bf45a
>
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
>
>
> On Tue, Sep 9, 2014 at 10:42 AM, Martin Grigorov <mg...@apache.org>
> wrote:
>
>> Please check that the solution provided with
>> https://issues.apache.org/jira/browse/WICKET-5694 will do the job.
>>
>> Martin Grigorov
>> Wicket Training and Consulting
>> https://twitter.com/mtgrigorov
>>
>>
>> On Mon, Sep 8, 2014 at 10:45 AM, Thibault Kruse <ti...@googlemail.com>
>> wrote:
>>
>>> Hm, thinking some more, the general solution would be to fail if a
>>> variant is requested, and it is among a set of whitelisted variants,
>>> and the markup is not found. For other variants, using the default
>>> would probably be fine. This is more general than our current usecase,
>>> but still significant I believe. I trust that Wicket fails at runtime
>>> when the markup has an error, and I want to be able to express in
>>> wicket that for a given component, a set of variants is expected to
>>> exist, and wicket should fail if the markup is missing for any variant
>>> in the set.
>>>
>>> On Mon, Sep 8, 2014 at 9:41 AM, Thibault Kruse <ti...@googlemail.com>
>>> wrote:
>>> > Both solutions are not ideal, since we do not want our tests to become
>>> > brittle. We want to functionally test components in multiple variants,
>>> > but where the variants vary in mere layout (css classes), we do not
>>> > want to have tests break just because the layout changes (as long as
>>> > the component still functions).
>>> >
>>> > Another solution for us would be to have components without variant
>>> > loading fallback behavior. So in general it is obviously good if a
>>> > component falls back to default markup, because we might have a
>>> > component tree where only a subset of involved components have a
>>> > variant markup. But for those component are supposed to have it, it
>>> > would be good if they fail when it is not found (e.g. due to typos).
>>> > However, I guess we cannot implement that logic inside getVariant(),
>>> > as the child components will invoke it. Is there another hook we could
>>> > use to fail for specific components when their variant was not found?
>>> >
>>> > On Mon, Sep 8, 2014 at 9:12 AM, Martin Grigorov <mg...@apache.org>
>>> wrote:
>>> >> Hi,
>>> >>
>>> >> There is nothing specific for this.
>>> >> But you can use
>>> >> various org.apache.wicket.util.tester.WicketTester#executeTest()
>>> methods to
>>> >> check the response against a valid response pre-saved in a file.
>>> >> Or you can use
>>> org.apache.wicket.util.tester.WicketTester#assertContains()
>>> >> to check that a specific String (actually a Regex) is in the response.
>>> >>
>>> >> Martin Grigorov
>>> >> Wicket Training and Consulting
>>> >> https://twitter.com/mtgrigorov
>>> >>
>>> >>
>>> >> On Fri, Sep 5, 2014 at 4:30 PM, Thibault Kruse <
>>> tibokruse@googlemail.com>
>>> >> wrote:
>>> >>
>>> >>> Thanks Martin,
>>> >>>
>>> >>> that works for us. I missed that Variants are inherited from parents.
>>> >>>
>>> >>> Is there also a good way that I can assure in our unit tests that the
>>> >>> variant markup for certain components exists and was found? Else a
>>> >>> typo would go unnoticed in the unit tests.
>>> >>>
>>> >>> cheers,
>>> >>> Thibault
>>> >>>
>>> >>> On Wed, Sep 3, 2014 at 12:59 PM, Martin Grigorov <
>>> mgrigorov@apache.org>
>>> >>> wrote:
>>> >>> > Hi,
>>> >>> >
>>> >>> > The behaviors are not used for variations.
>>> >>> > For such use cases you should
>>> >>> > override org.apache.wicket.Component#getVariation() on the (base)
>>> page.
>>> >>> > This way all components will know the correct variation.
>>> >>> >
>>> >>> > Martin Grigorov
>>> >>> > Wicket Training and Consulting
>>> >>> > https://twitter.com/mtgrigorov
>>> >>> >
>>> >>> >
>>> >>> > On Wed, Sep 3, 2014 at 1:09 PM, Thibault Kruse <
>>> tibokruse@googlemail.com
>>> >>> >
>>> >>> > wrote:
>>> >>> >
>>> >>> >> Hi,
>>> >>> >>
>>> >>> >> playing around with Variants for Components, I am wondering whether
>>> >>> >> there is an elegant way to steer Variant markup loading via a
>>> >>> >> Behavior.
>>> >>> >>
>>> >>> >> In our case we want to use a different markup layout based on the
>>> >>> >> width of the container the component is going to be used in,
>>> visually.
>>> >>> >>
>>> >>> >> So if we imagine a Browser window with desktop size, we might want
>>> to
>>> >>> >> use a component on the full width, on a third of the width, or a
>>> >>> >> quarter of the width.
>>> >>> >>
>>> >>> >> For each such container width, we need different responsive design
>>> >>> >> markup. Since this may affect many of our components which inherit
>>> >>> >> from different wicket components, I'd like to just add another html
>>> >>> >> markup file for the variant, and add a Behavior to the component
>>> that
>>> >>> >> decides the Variant.
>>> >>> >>
>>> >>> >> cheers,
>>> >>> >> Thibault
>>> >>> >>
>>> >>> >>
>>> ---------------------------------------------------------------------
>>> >>> >> 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
>>> >>>
>>> >>>
>>>
>>> ---------------------------------------------------------------------
>>> 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: Variant Change Behavior
Posted by Martin Grigorov <mg...@apache.org>.
https://git-wip-us.apache.org/repos/asf?p=wicket.git;a=commit;h=702bf45a
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
On Tue, Sep 9, 2014 at 10:42 AM, Martin Grigorov <mg...@apache.org>
wrote:
> Please check that the solution provided with
> https://issues.apache.org/jira/browse/WICKET-5694 will do the job.
>
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
>
>
> On Mon, Sep 8, 2014 at 10:45 AM, Thibault Kruse <ti...@googlemail.com>
> wrote:
>
>> Hm, thinking some more, the general solution would be to fail if a
>> variant is requested, and it is among a set of whitelisted variants,
>> and the markup is not found. For other variants, using the default
>> would probably be fine. This is more general than our current usecase,
>> but still significant I believe. I trust that Wicket fails at runtime
>> when the markup has an error, and I want to be able to express in
>> wicket that for a given component, a set of variants is expected to
>> exist, and wicket should fail if the markup is missing for any variant
>> in the set.
>>
>> On Mon, Sep 8, 2014 at 9:41 AM, Thibault Kruse <ti...@googlemail.com>
>> wrote:
>> > Both solutions are not ideal, since we do not want our tests to become
>> > brittle. We want to functionally test components in multiple variants,
>> > but where the variants vary in mere layout (css classes), we do not
>> > want to have tests break just because the layout changes (as long as
>> > the component still functions).
>> >
>> > Another solution for us would be to have components without variant
>> > loading fallback behavior. So in general it is obviously good if a
>> > component falls back to default markup, because we might have a
>> > component tree where only a subset of involved components have a
>> > variant markup. But for those component are supposed to have it, it
>> > would be good if they fail when it is not found (e.g. due to typos).
>> > However, I guess we cannot implement that logic inside getVariant(),
>> > as the child components will invoke it. Is there another hook we could
>> > use to fail for specific components when their variant was not found?
>> >
>> > On Mon, Sep 8, 2014 at 9:12 AM, Martin Grigorov <mg...@apache.org>
>> wrote:
>> >> Hi,
>> >>
>> >> There is nothing specific for this.
>> >> But you can use
>> >> various org.apache.wicket.util.tester.WicketTester#executeTest()
>> methods to
>> >> check the response against a valid response pre-saved in a file.
>> >> Or you can use
>> org.apache.wicket.util.tester.WicketTester#assertContains()
>> >> to check that a specific String (actually a Regex) is in the response.
>> >>
>> >> Martin Grigorov
>> >> Wicket Training and Consulting
>> >> https://twitter.com/mtgrigorov
>> >>
>> >>
>> >> On Fri, Sep 5, 2014 at 4:30 PM, Thibault Kruse <
>> tibokruse@googlemail.com>
>> >> wrote:
>> >>
>> >>> Thanks Martin,
>> >>>
>> >>> that works for us. I missed that Variants are inherited from parents.
>> >>>
>> >>> Is there also a good way that I can assure in our unit tests that the
>> >>> variant markup for certain components exists and was found? Else a
>> >>> typo would go unnoticed in the unit tests.
>> >>>
>> >>> cheers,
>> >>> Thibault
>> >>>
>> >>> On Wed, Sep 3, 2014 at 12:59 PM, Martin Grigorov <
>> mgrigorov@apache.org>
>> >>> wrote:
>> >>> > Hi,
>> >>> >
>> >>> > The behaviors are not used for variations.
>> >>> > For such use cases you should
>> >>> > override org.apache.wicket.Component#getVariation() on the (base)
>> page.
>> >>> > This way all components will know the correct variation.
>> >>> >
>> >>> > Martin Grigorov
>> >>> > Wicket Training and Consulting
>> >>> > https://twitter.com/mtgrigorov
>> >>> >
>> >>> >
>> >>> > On Wed, Sep 3, 2014 at 1:09 PM, Thibault Kruse <
>> tibokruse@googlemail.com
>> >>> >
>> >>> > wrote:
>> >>> >
>> >>> >> Hi,
>> >>> >>
>> >>> >> playing around with Variants for Components, I am wondering whether
>> >>> >> there is an elegant way to steer Variant markup loading via a
>> >>> >> Behavior.
>> >>> >>
>> >>> >> In our case we want to use a different markup layout based on the
>> >>> >> width of the container the component is going to be used in,
>> visually.
>> >>> >>
>> >>> >> So if we imagine a Browser window with desktop size, we might want
>> to
>> >>> >> use a component on the full width, on a third of the width, or a
>> >>> >> quarter of the width.
>> >>> >>
>> >>> >> For each such container width, we need different responsive design
>> >>> >> markup. Since this may affect many of our components which inherit
>> >>> >> from different wicket components, I'd like to just add another html
>> >>> >> markup file for the variant, and add a Behavior to the component
>> that
>> >>> >> decides the Variant.
>> >>> >>
>> >>> >> cheers,
>> >>> >> Thibault
>> >>> >>
>> >>> >>
>> ---------------------------------------------------------------------
>> >>> >> 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
>> >>>
>> >>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
Re: Variant Change Behavior
Posted by Martin Grigorov <mg...@apache.org>.
Please check that the solution provided with
https://issues.apache.org/jira/browse/WICKET-5694 will do the job.
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
On Mon, Sep 8, 2014 at 10:45 AM, Thibault Kruse <ti...@googlemail.com>
wrote:
> Hm, thinking some more, the general solution would be to fail if a
> variant is requested, and it is among a set of whitelisted variants,
> and the markup is not found. For other variants, using the default
> would probably be fine. This is more general than our current usecase,
> but still significant I believe. I trust that Wicket fails at runtime
> when the markup has an error, and I want to be able to express in
> wicket that for a given component, a set of variants is expected to
> exist, and wicket should fail if the markup is missing for any variant
> in the set.
>
> On Mon, Sep 8, 2014 at 9:41 AM, Thibault Kruse <ti...@googlemail.com>
> wrote:
> > Both solutions are not ideal, since we do not want our tests to become
> > brittle. We want to functionally test components in multiple variants,
> > but where the variants vary in mere layout (css classes), we do not
> > want to have tests break just because the layout changes (as long as
> > the component still functions).
> >
> > Another solution for us would be to have components without variant
> > loading fallback behavior. So in general it is obviously good if a
> > component falls back to default markup, because we might have a
> > component tree where only a subset of involved components have a
> > variant markup. But for those component are supposed to have it, it
> > would be good if they fail when it is not found (e.g. due to typos).
> > However, I guess we cannot implement that logic inside getVariant(),
> > as the child components will invoke it. Is there another hook we could
> > use to fail for specific components when their variant was not found?
> >
> > On Mon, Sep 8, 2014 at 9:12 AM, Martin Grigorov <mg...@apache.org>
> wrote:
> >> Hi,
> >>
> >> There is nothing specific for this.
> >> But you can use
> >> various org.apache.wicket.util.tester.WicketTester#executeTest()
> methods to
> >> check the response against a valid response pre-saved in a file.
> >> Or you can use
> org.apache.wicket.util.tester.WicketTester#assertContains()
> >> to check that a specific String (actually a Regex) is in the response.
> >>
> >> Martin Grigorov
> >> Wicket Training and Consulting
> >> https://twitter.com/mtgrigorov
> >>
> >>
> >> On Fri, Sep 5, 2014 at 4:30 PM, Thibault Kruse <
> tibokruse@googlemail.com>
> >> wrote:
> >>
> >>> Thanks Martin,
> >>>
> >>> that works for us. I missed that Variants are inherited from parents.
> >>>
> >>> Is there also a good way that I can assure in our unit tests that the
> >>> variant markup for certain components exists and was found? Else a
> >>> typo would go unnoticed in the unit tests.
> >>>
> >>> cheers,
> >>> Thibault
> >>>
> >>> On Wed, Sep 3, 2014 at 12:59 PM, Martin Grigorov <mgrigorov@apache.org
> >
> >>> wrote:
> >>> > Hi,
> >>> >
> >>> > The behaviors are not used for variations.
> >>> > For such use cases you should
> >>> > override org.apache.wicket.Component#getVariation() on the (base)
> page.
> >>> > This way all components will know the correct variation.
> >>> >
> >>> > Martin Grigorov
> >>> > Wicket Training and Consulting
> >>> > https://twitter.com/mtgrigorov
> >>> >
> >>> >
> >>> > On Wed, Sep 3, 2014 at 1:09 PM, Thibault Kruse <
> tibokruse@googlemail.com
> >>> >
> >>> > wrote:
> >>> >
> >>> >> Hi,
> >>> >>
> >>> >> playing around with Variants for Components, I am wondering whether
> >>> >> there is an elegant way to steer Variant markup loading via a
> >>> >> Behavior.
> >>> >>
> >>> >> In our case we want to use a different markup layout based on the
> >>> >> width of the container the component is going to be used in,
> visually.
> >>> >>
> >>> >> So if we imagine a Browser window with desktop size, we might want
> to
> >>> >> use a component on the full width, on a third of the width, or a
> >>> >> quarter of the width.
> >>> >>
> >>> >> For each such container width, we need different responsive design
> >>> >> markup. Since this may affect many of our components which inherit
> >>> >> from different wicket components, I'd like to just add another html
> >>> >> markup file for the variant, and add a Behavior to the component
> that
> >>> >> decides the Variant.
> >>> >>
> >>> >> cheers,
> >>> >> Thibault
> >>> >>
> >>> >>
> ---------------------------------------------------------------------
> >>> >> 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
> >>>
> >>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Variant Change Behavior
Posted by Thibault Kruse <ti...@googlemail.com>.
Hm, thinking some more, the general solution would be to fail if a
variant is requested, and it is among a set of whitelisted variants,
and the markup is not found. For other variants, using the default
would probably be fine. This is more general than our current usecase,
but still significant I believe. I trust that Wicket fails at runtime
when the markup has an error, and I want to be able to express in
wicket that for a given component, a set of variants is expected to
exist, and wicket should fail if the markup is missing for any variant
in the set.
On Mon, Sep 8, 2014 at 9:41 AM, Thibault Kruse <ti...@googlemail.com> wrote:
> Both solutions are not ideal, since we do not want our tests to become
> brittle. We want to functionally test components in multiple variants,
> but where the variants vary in mere layout (css classes), we do not
> want to have tests break just because the layout changes (as long as
> the component still functions).
>
> Another solution for us would be to have components without variant
> loading fallback behavior. So in general it is obviously good if a
> component falls back to default markup, because we might have a
> component tree where only a subset of involved components have a
> variant markup. But for those component are supposed to have it, it
> would be good if they fail when it is not found (e.g. due to typos).
> However, I guess we cannot implement that logic inside getVariant(),
> as the child components will invoke it. Is there another hook we could
> use to fail for specific components when their variant was not found?
>
> On Mon, Sep 8, 2014 at 9:12 AM, Martin Grigorov <mg...@apache.org> wrote:
>> Hi,
>>
>> There is nothing specific for this.
>> But you can use
>> various org.apache.wicket.util.tester.WicketTester#executeTest() methods to
>> check the response against a valid response pre-saved in a file.
>> Or you can use org.apache.wicket.util.tester.WicketTester#assertContains()
>> to check that a specific String (actually a Regex) is in the response.
>>
>> Martin Grigorov
>> Wicket Training and Consulting
>> https://twitter.com/mtgrigorov
>>
>>
>> On Fri, Sep 5, 2014 at 4:30 PM, Thibault Kruse <ti...@googlemail.com>
>> wrote:
>>
>>> Thanks Martin,
>>>
>>> that works for us. I missed that Variants are inherited from parents.
>>>
>>> Is there also a good way that I can assure in our unit tests that the
>>> variant markup for certain components exists and was found? Else a
>>> typo would go unnoticed in the unit tests.
>>>
>>> cheers,
>>> Thibault
>>>
>>> On Wed, Sep 3, 2014 at 12:59 PM, Martin Grigorov <mg...@apache.org>
>>> wrote:
>>> > Hi,
>>> >
>>> > The behaviors are not used for variations.
>>> > For such use cases you should
>>> > override org.apache.wicket.Component#getVariation() on the (base) page.
>>> > This way all components will know the correct variation.
>>> >
>>> > Martin Grigorov
>>> > Wicket Training and Consulting
>>> > https://twitter.com/mtgrigorov
>>> >
>>> >
>>> > On Wed, Sep 3, 2014 at 1:09 PM, Thibault Kruse <tibokruse@googlemail.com
>>> >
>>> > wrote:
>>> >
>>> >> Hi,
>>> >>
>>> >> playing around with Variants for Components, I am wondering whether
>>> >> there is an elegant way to steer Variant markup loading via a
>>> >> Behavior.
>>> >>
>>> >> In our case we want to use a different markup layout based on the
>>> >> width of the container the component is going to be used in, visually.
>>> >>
>>> >> So if we imagine a Browser window with desktop size, we might want to
>>> >> use a component on the full width, on a third of the width, or a
>>> >> quarter of the width.
>>> >>
>>> >> For each such container width, we need different responsive design
>>> >> markup. Since this may affect many of our components which inherit
>>> >> from different wicket components, I'd like to just add another html
>>> >> markup file for the variant, and add a Behavior to the component that
>>> >> decides the Variant.
>>> >>
>>> >> cheers,
>>> >> Thibault
>>> >>
>>> >> ---------------------------------------------------------------------
>>> >> 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
>>>
>>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Variant Change Behavior
Posted by Thibault Kruse <ti...@googlemail.com>.
Both solutions are not ideal, since we do not want our tests to become
brittle. We want to functionally test components in multiple variants,
but where the variants vary in mere layout (css classes), we do not
want to have tests break just because the layout changes (as long as
the component still functions).
Another solution for us would be to have components without variant
loading fallback behavior. So in general it is obviously good if a
component falls back to default markup, because we might have a
component tree where only a subset of involved components have a
variant markup. But for those component are supposed to have it, it
would be good if they fail when it is not found (e.g. due to typos).
However, I guess we cannot implement that logic inside getVariant(),
as the child components will invoke it. Is there another hook we could
use to fail for specific components when their variant was not found?
On Mon, Sep 8, 2014 at 9:12 AM, Martin Grigorov <mg...@apache.org> wrote:
> Hi,
>
> There is nothing specific for this.
> But you can use
> various org.apache.wicket.util.tester.WicketTester#executeTest() methods to
> check the response against a valid response pre-saved in a file.
> Or you can use org.apache.wicket.util.tester.WicketTester#assertContains()
> to check that a specific String (actually a Regex) is in the response.
>
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
>
>
> On Fri, Sep 5, 2014 at 4:30 PM, Thibault Kruse <ti...@googlemail.com>
> wrote:
>
>> Thanks Martin,
>>
>> that works for us. I missed that Variants are inherited from parents.
>>
>> Is there also a good way that I can assure in our unit tests that the
>> variant markup for certain components exists and was found? Else a
>> typo would go unnoticed in the unit tests.
>>
>> cheers,
>> Thibault
>>
>> On Wed, Sep 3, 2014 at 12:59 PM, Martin Grigorov <mg...@apache.org>
>> wrote:
>> > Hi,
>> >
>> > The behaviors are not used for variations.
>> > For such use cases you should
>> > override org.apache.wicket.Component#getVariation() on the (base) page.
>> > This way all components will know the correct variation.
>> >
>> > Martin Grigorov
>> > Wicket Training and Consulting
>> > https://twitter.com/mtgrigorov
>> >
>> >
>> > On Wed, Sep 3, 2014 at 1:09 PM, Thibault Kruse <tibokruse@googlemail.com
>> >
>> > wrote:
>> >
>> >> Hi,
>> >>
>> >> playing around with Variants for Components, I am wondering whether
>> >> there is an elegant way to steer Variant markup loading via a
>> >> Behavior.
>> >>
>> >> In our case we want to use a different markup layout based on the
>> >> width of the container the component is going to be used in, visually.
>> >>
>> >> So if we imagine a Browser window with desktop size, we might want to
>> >> use a component on the full width, on a third of the width, or a
>> >> quarter of the width.
>> >>
>> >> For each such container width, we need different responsive design
>> >> markup. Since this may affect many of our components which inherit
>> >> from different wicket components, I'd like to just add another html
>> >> markup file for the variant, and add a Behavior to the component that
>> >> decides the Variant.
>> >>
>> >> cheers,
>> >> Thibault
>> >>
>> >> ---------------------------------------------------------------------
>> >> 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
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Variant Change Behavior
Posted by Martin Grigorov <mg...@apache.org>.
Hi,
There is nothing specific for this.
But you can use
various org.apache.wicket.util.tester.WicketTester#executeTest() methods to
check the response against a valid response pre-saved in a file.
Or you can use org.apache.wicket.util.tester.WicketTester#assertContains()
to check that a specific String (actually a Regex) is in the response.
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
On Fri, Sep 5, 2014 at 4:30 PM, Thibault Kruse <ti...@googlemail.com>
wrote:
> Thanks Martin,
>
> that works for us. I missed that Variants are inherited from parents.
>
> Is there also a good way that I can assure in our unit tests that the
> variant markup for certain components exists and was found? Else a
> typo would go unnoticed in the unit tests.
>
> cheers,
> Thibault
>
> On Wed, Sep 3, 2014 at 12:59 PM, Martin Grigorov <mg...@apache.org>
> wrote:
> > Hi,
> >
> > The behaviors are not used for variations.
> > For such use cases you should
> > override org.apache.wicket.Component#getVariation() on the (base) page.
> > This way all components will know the correct variation.
> >
> > Martin Grigorov
> > Wicket Training and Consulting
> > https://twitter.com/mtgrigorov
> >
> >
> > On Wed, Sep 3, 2014 at 1:09 PM, Thibault Kruse <tibokruse@googlemail.com
> >
> > wrote:
> >
> >> Hi,
> >>
> >> playing around with Variants for Components, I am wondering whether
> >> there is an elegant way to steer Variant markup loading via a
> >> Behavior.
> >>
> >> In our case we want to use a different markup layout based on the
> >> width of the container the component is going to be used in, visually.
> >>
> >> So if we imagine a Browser window with desktop size, we might want to
> >> use a component on the full width, on a third of the width, or a
> >> quarter of the width.
> >>
> >> For each such container width, we need different responsive design
> >> markup. Since this may affect many of our components which inherit
> >> from different wicket components, I'd like to just add another html
> >> markup file for the variant, and add a Behavior to the component that
> >> decides the Variant.
> >>
> >> cheers,
> >> Thibault
> >>
> >> ---------------------------------------------------------------------
> >> 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: Variant Change Behavior
Posted by Thibault Kruse <ti...@googlemail.com>.
Thanks Martin,
that works for us. I missed that Variants are inherited from parents.
Is there also a good way that I can assure in our unit tests that the
variant markup for certain components exists and was found? Else a
typo would go unnoticed in the unit tests.
cheers,
Thibault
On Wed, Sep 3, 2014 at 12:59 PM, Martin Grigorov <mg...@apache.org> wrote:
> Hi,
>
> The behaviors are not used for variations.
> For such use cases you should
> override org.apache.wicket.Component#getVariation() on the (base) page.
> This way all components will know the correct variation.
>
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
>
>
> On Wed, Sep 3, 2014 at 1:09 PM, Thibault Kruse <ti...@googlemail.com>
> wrote:
>
>> Hi,
>>
>> playing around with Variants for Components, I am wondering whether
>> there is an elegant way to steer Variant markup loading via a
>> Behavior.
>>
>> In our case we want to use a different markup layout based on the
>> width of the container the component is going to be used in, visually.
>>
>> So if we imagine a Browser window with desktop size, we might want to
>> use a component on the full width, on a third of the width, or a
>> quarter of the width.
>>
>> For each such container width, we need different responsive design
>> markup. Since this may affect many of our components which inherit
>> from different wicket components, I'd like to just add another html
>> markup file for the variant, and add a Behavior to the component that
>> decides the Variant.
>>
>> cheers,
>> Thibault
>>
>> ---------------------------------------------------------------------
>> 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: Variant Change Behavior
Posted by Martin Grigorov <mg...@apache.org>.
Hi,
The behaviors are not used for variations.
For such use cases you should
override org.apache.wicket.Component#getVariation() on the (base) page.
This way all components will know the correct variation.
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
On Wed, Sep 3, 2014 at 1:09 PM, Thibault Kruse <ti...@googlemail.com>
wrote:
> Hi,
>
> playing around with Variants for Components, I am wondering whether
> there is an elegant way to steer Variant markup loading via a
> Behavior.
>
> In our case we want to use a different markup layout based on the
> width of the container the component is going to be used in, visually.
>
> So if we imagine a Browser window with desktop size, we might want to
> use a component on the full width, on a third of the width, or a
> quarter of the width.
>
> For each such container width, we need different responsive design
> markup. Since this may affect many of our components which inherit
> from different wicket components, I'd like to just add another html
> markup file for the variant, and add a Behavior to the component that
> decides the Variant.
>
> cheers,
> Thibault
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>