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
>>
>>
>

Reply via email to