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
