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 :
>
> On Tue, Jan 27, 2015 at 9:16 AM, Tobias Soloschenko <
> tobias
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 vali
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#getF
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
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 :
>
> Hi Tobias,
>
> Have you considered using
> https://github.com/adobe-webplatform/css-shap
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 Wick
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 ?
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", "murks
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,