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