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 <tibokr...@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 <mgrigo...@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 <tibokr...@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 <mgrigo...@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 <tibokr...@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-unsubscr...@wicket.apache.org
>>> >> For additional commands, e-mail: users-h...@wicket.apache.org
>>> >>
>>> >>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>
>>>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Reply via email to