Re: Variant Change Behavior
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
Re: Variant Change Behavior
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
Re: Variant Change Behavior
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
Re: Variant Change Behavior
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
Re: Variant Change Behavior
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
Re: Variant Change Behavior
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
Re: Variant Change Behavior
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
Re: Variant Change Behavior
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
