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