AttributeAppender seems to be ignored in AbstractAjaxBehavior.onComponentTag
Hi all, I have a class extending AbstractAjaxBehavior and overriding onComponentTag(ComponentTag tag), because I need a custom css class added. I thought this would be an easy task by simply adding an AttributeAppender like the following: tag.addBehavior(AttributeModifier.append(class, murks2)); But that doesn't work, the class attribute retains it's initial value. If I add low level like the following the attribute's value changes successfully: tag.append(class, murks, ); I googled a bit and found one thread about AjaxLink and the same problem, but no description on why using AttributeModifier doesn't work and I don't even use AjaxLink at all. Am I doing something wrong or is this intended behavior? In the latter case, what should I do to let my AjaxBehavior change the class attribute? Thanks for your help! Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail: thorsten.schoen...@am-soft.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon...05151- 9468- 55 Fax...05151- 9468- 88 Mobil..0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: JSR356 Websocket with Wicket 6.18
Hi, JSR356 API jar is built with Java 7. This is the main reason why this module is not part of Wicket 6.x. If this single method is the only problem to use wicket-native-websocket-javax:7.0.0-M4 with Wicket 6.18.0 then please create a ticket in JIRA and we will make it public for 6.20.0. I think 7.0.0-M5 (currently being in vote) is as stable as 6.19.0 (also in vote). There were no API breaks since 7.0.0-M4 and hopefully M5 will be released as 7.0.0.Final in few weeks. We need your feedback now! It is mite annoying that most users don't want to even try it because of naming conventions :-/ Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Tue, Jan 27, 2015 at 11:08 AM, Alexander Landsnes Keül alexander.landsnes.k...@visma.com wrote: Reading the documentation I was under the impression that wicket-native-websocket-javax could be used along with Wicket 6.X, however that seems to not be the case. In the constructor of org.apache.wicket.protocol.ws.api.AbstractWebSocketProcessor line 120 (7.0.0-M4) it accesses WicketFilter#getFilterPath(), which is public in Wicket 7 but private in Wicket 6.X. Is there a way to sort this, or do I simply have to wait until Wicket 7 is finalized? Upgrading while it's a milestone release isn't an option, sadly, but on the other hand we just upgraded to Tomcat 8 and not having a functional websocket implementation is a mite annoying. Alex
JSR356 Websocket with Wicket 6.18
Reading the documentation I was under the impression that wicket-native-websocket-javax could be used along with Wicket 6.X, however that seems to not be the case. In the constructor of org.apache.wicket.protocol.ws.api.AbstractWebSocketProcessor line 120 (7.0.0-M4) it accesses WicketFilter#getFilterPath(), which is public in Wicket 7 but private in Wicket 6.X. Is there a way to sort this, or do I simply have to wait until Wicket 7 is finalized? Upgrading while it's a milestone release isn't an option, sadly, but on the other hand we just upgraded to Tomcat 8 and not having a functional websocket implementation is a mite annoying. Alex
Re: Internationalized Validators
Yes! This will make the component tree a bit heavier but it would definitely simplify the code! Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Tue, Jan 27, 2015 at 10:02 AM, Tobias Soloschenko tobiassolosche...@googlemail.com wrote: You could apply the validator without any switch and build in a check which receives the Session Locale and only apply the validation if the locale is en_US kind regards Tobias Am 27.01.2015 um 08:40 schrieb Martin Grigorov mgrigo...@apache.org: On Tue, Jan 27, 2015 at 9:16 AM, Tobias Soloschenko tobiassolosche...@googlemail.com wrote: Ah, just one addition: No you would not require to switch the parameter, because the parameter would remain the same - in the property files it would look like this: Propertyfile for en_GB: maxvalue=200 Propertyfile for de_DE: maxvalue=100 in the code you would receive the max value based on the current locale getString(maxvalue) This will work if the app code uses the same type of validator with different arguments, but it won't work if for some locales/markets it has to use a completely different validator (like AnotherValidatorOnlyForUS). But yes, it would simplify the switch! kind regards Tobias Am 27.01.2015 um 07:38 schrieb Christian Schröter christian.schroe...@1und1.de: Thank you Tobias, but this will unfortunately just solve the problem having the same validator with different parameters. To add a market specific validator, I still would need to switch case the locale. Any other ideas? Hi, you could place the values in the locale file and parse them. Integer.parseInt(getString(maxvalue)); kind regards Tobias Am 26.01.2015 um 11:01 schrieb Christian Schröter christian.schroe...@1und1.de: Hey, I would be interested to know if there is a builtin mechanism to add specific validators for a certain locale. For example: de_DE - StringValidator.maximumLength(100) en_GB - StringValidator.maximumLength(200); en_US - StringValidator.maximumLength(200); AnotherValidatorOnlyForUS(); My current solution is a switch-case over the locale to add the correct validators. With more locales and more validators this solution feels kind of sloppy. What does your solution looks like? Cheers, Chris - 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
Re: Internationalized Validators
You could apply the validator without any switch and build in a check which receives the Session Locale and only apply the validation if the locale is en_US kind regards Tobias Am 27.01.2015 um 08:40 schrieb Martin Grigorov mgrigo...@apache.org: On Tue, Jan 27, 2015 at 9:16 AM, Tobias Soloschenko tobiassolosche...@googlemail.com wrote: Ah, just one addition: No you would not require to switch the parameter, because the parameter would remain the same - in the property files it would look like this: Propertyfile for en_GB: maxvalue=200 Propertyfile for de_DE: maxvalue=100 in the code you would receive the max value based on the current locale getString(maxvalue) This will work if the app code uses the same type of validator with different arguments, but it won't work if for some locales/markets it has to use a completely different validator (like AnotherValidatorOnlyForUS). But yes, it would simplify the switch! kind regards Tobias Am 27.01.2015 um 07:38 schrieb Christian Schröter christian.schroe...@1und1.de: Thank you Tobias, but this will unfortunately just solve the problem having the same validator with different parameters. To add a market specific validator, I still would need to switch case the locale. Any other ideas? Hi, you could place the values in the locale file and parse them. Integer.parseInt(getString(maxvalue)); kind regards Tobias Am 26.01.2015 um 11:01 schrieb Christian Schröter christian.schroe...@1und1.de: Hey, I would be interested to know if there is a builtin mechanism to add specific validators for a certain locale. For example: de_DE - StringValidator.maximumLength(100) en_GB - StringValidator.maximumLength(200); en_US - StringValidator.maximumLength(200); AnotherValidatorOnlyForUS(); My current solution is a switch-case over the locale to add the correct validators. With more locales and more validators this solution feels kind of sloppy. What does your solution looks like? Cheers, Chris - 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
Re: AttributeAppender seems to be ignored in AbstractAjaxBehavior.onComponentTag
Hi Thorsten, adding a behavior to the tag is nothing you would want to do in your behavior, because it's too late to have any effect on the current rendering (see Component#renderComponentTag()). Behaviors on markup tags are meant to be used to alter the markup independent of any component, see RelativePathPrefixHandler and WicketMessageTagHandler for inspiration. what should I do to let my AjaxBehavior change the class attribute? The following is just fine: tag.append(class, murks, ); Regards Sven On 27.01.2015 19:25, Thorsten Schöning wrote: Hi all, I have a class extending AbstractAjaxBehavior and overriding onComponentTag(ComponentTag tag), because I need a custom css class added. I thought this would be an easy task by simply adding an AttributeAppender like the following: tag.addBehavior(AttributeModifier.append(class, murks2)); But that doesn't work, the class attribute retains it's initial value. If I add low level like the following the attribute's value changes successfully: tag.append(class, murks, ); I googled a bit and found one thread about AjaxLink and the same problem, but no description on why using AttributeModifier doesn't work and I don't even use AjaxLink at all. Am I doing something wrong or is this intended behavior? In the latter case, what should I do to let my AjaxBehavior change the class attribute? Thanks for your help! Mit freundlichen Grüßen, Thorsten Schöning - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
RE: JSR356 Websocket with Wicket 6.18
I checked out Wicket 6.18 and fiddled a bit with it, but it seems there are a few minor API breaks. One of the most pervasive ones is Application#setMetaData(...), in 6.18.0 it's a void function while 7.0.0-M4 returns this for chaining. I'm not sure JSR356 should be listed as an option for Wicket 6.x. It's certainly possible to fix it without too much effort, but since it changes a few signatures in wicket-core it requires all the projects checked out and modified. I don't have the time for it right now, and I do quite understand it if no one else feels like spending the time either. Naming conventions are the spice of policies. Milestones are viewed as dangerously buggy and unstable, and hence unfit for the hallowed halls of shippable code. I may try to sneak it in nonetheless, since I do need websocket support and the stable release is weeks away. Alex -Original Message- From: Martin Grigorov [mailto:mgrigo...@apache.org] Sent: 27 January 2015 10:30 To: users@wicket.apache.org Subject: Re: JSR356 Websocket with Wicket 6.18 Hi, JSR356 API jar is built with Java 7. This is the main reason why this module is not part of Wicket 6.x. If this single method is the only problem to use wicket-native-websocket-javax:7.0.0-M4 with Wicket 6.18.0 then please create a ticket in JIRA and we will make it public for 6.20.0. I think 7.0.0-M5 (currently being in vote) is as stable as 6.19.0 (also in vote). There were no API breaks since 7.0.0-M4 and hopefully M5 will be released as 7.0.0.Final in few weeks. We need your feedback now! It is mite annoying that most users don't want to even try it because of naming conventions :-/ Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Tue, Jan 27, 2015 at 11:08 AM, Alexander Landsnes Keül alexander.landsnes.k...@visma.com wrote: Reading the documentation I was under the impression that wicket-native-websocket-javax could be used along with Wicket 6.X, however that seems to not be the case. In the constructor of org.apache.wicket.protocol.ws.api.AbstractWebSocketProcessor line 120 (7.0.0-M4) it accesses WicketFilter#getFilterPath(), which is public in Wicket 7 but private in Wicket 6.X. Is there a way to sort this, or do I simply have to wait until Wicket 7 is finalized? Upgrading while it's a milestone release isn't an option, sadly, but on the other hand we just upgraded to Tomcat 8 and not having a functional websocket implementation is a mite annoying. Alex
Re: HTML5 CSS Shapes
Hi again, API changes are made - the polyfill is not working with float of blockelements. Looking forward to provide a demo. :-) kind regards Tobias Am 27.01.2015 um 08:37 schrieb Martin Grigorov mgrigo...@apache.org: Hi Tobias, Have you considered using https://github.com/adobe-webplatform/css-shapes-polyfill as a fallback for the browsers which do not yet support the new feature ? About the API: #shapeType(new CircleShapeType(...)) #transitionShapeType(new CircleShapeType(50%)) I find the names a bit repetitive - too many shapeTypes to write/read :-) Maybe #shape(new Circle(...)) and #transition(new Circle(...)) will be enough ?! It would be easier for us to understand what you are talking about if we see the demo in action :-) I am a happy user of RedHat's OpenShift as a free service for deploying Java apps. Thank you for all your contributions to Wicket and WicketStuff you do lately! Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Mon, Jan 26, 2015 at 10:07 PM, Tobias Soloschenko tobiassolosche...@googlemail.com wrote: Hi everyone, I was just playing around a little bit with shape-outside and wrapped the css stuff into a small wicket component. https://github.com/klopfdreh/wicket-components-playground (Search for HTML5 Shapes) The browsers which support this functionality are listed here: http://caniuse.com/#search=shape-outside I also provided a little demo page org.wicketstuff.html5.shape.example.ShapeCircleExamplePage. It's a fluent API / an example is listed in the repository. kind regards Tobias - 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: JSR356 Websocket with Wicket 6.18
The needed changes to make -javax module working with Wicket 6.x are not too big. I think the easiest way to make it available for Wicket 6.x is to add (a clone/copy of) the module to WicketStuff project. This way it could be part of 6.19.0 too. Is this something you are interested to help with ? On Tue, Jan 27, 2015 at 2:11 PM, Alexander Landsnes Keül alexander.landsnes.k...@visma.com wrote: I checked out Wicket 6.18 and fiddled a bit with it, but it seems there are a few minor API breaks. One of the most pervasive ones is Application#setMetaData(...), in 6.18.0 it's a void function while 7.0.0-M4 returns this for chaining. I'm not sure JSR356 should be listed as an option for Wicket 6.x. It's certainly possible to fix it without too much effort, but since it changes a few signatures in wicket-core it requires all the projects checked out and modified. I don't have the time for it right now, and I do quite understand it if no one else feels like spending the time either. Naming conventions are the spice of policies. Milestones are viewed as dangerously buggy and unstable, and hence unfit for the hallowed halls of shippable code. I may try to sneak it in nonetheless, since I do need websocket support and the stable release is weeks away. Alex -Original Message- From: Martin Grigorov [mailto:mgrigo...@apache.org] Sent: 27 January 2015 10:30 To: users@wicket.apache.org Subject: Re: JSR356 Websocket with Wicket 6.18 Hi, JSR356 API jar is built with Java 7. This is the main reason why this module is not part of Wicket 6.x. If this single method is the only problem to use wicket-native-websocket-javax:7.0.0-M4 with Wicket 6.18.0 then please create a ticket in JIRA and we will make it public for 6.20.0. I think 7.0.0-M5 (currently being in vote) is as stable as 6.19.0 (also in vote). There were no API breaks since 7.0.0-M4 and hopefully M5 will be released as 7.0.0.Final in few weeks. We need your feedback now! It is mite annoying that most users don't want to even try it because of naming conventions :-/ Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Tue, Jan 27, 2015 at 11:08 AM, Alexander Landsnes Keül alexander.landsnes.k...@visma.com wrote: Reading the documentation I was under the impression that wicket-native-websocket-javax could be used along with Wicket 6.X, however that seems to not be the case. In the constructor of org.apache.wicket.protocol.ws.api.AbstractWebSocketProcessor line 120 (7.0.0-M4) it accesses WicketFilter#getFilterPath(), which is public in Wicket 7 but private in Wicket 6.X. Is there a way to sort this, or do I simply have to wait until Wicket 7 is finalized? Upgrading while it's a milestone release isn't an option, sadly, but on the other hand we just upgraded to Tomcat 8 and not having a functional websocket implementation is a mite annoying. Alex
