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 <mgrigo...@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 <mgrigo...@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 <tibokr...@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 <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
>>>
>>>
>>

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

Reply via email to