Manage case when validating format against a regexp using the characters...

[ghost]

... '\A' and '\z' not supported in Javascript :

• Replaces '\A' with ^ and '\z' with $. Not the same meaning but enough for client-side validation

The problem happened when trying to validate an email against Devise default regex.

'\A' and '\z' are not recognized by the javascript regexp engine, causing the validation of an e-mail failing all the time.

Changing the default validation regex can be a problem as it ensures that an email is not spread over many lines. This is not critical for client side validation. That's why my preferred choice was to replace the characters with ^ and $ on the generated expression. We can then keep the strong validation on the server side.

I'm available if you've got any question on that topic.

Kind Regards,

Yann for the Silicon Salad Team

[joecorcoran]

Hi Yann!

Funnily enough, we had to deal with this exact problem earlier this week. It was related to the email_regexp config option in our old version of Devise.

I totally agree that this is a problem, but I'm hesitant to make a change to all client-side format validation just to handle this. There are so many differences between Ruby and JavaScript regular expressions and I don't feel like Judge should be the project to address them.

My preferred solution would be to use https://github.com/slevithan/XRegExp from within the JavaScript part of Judge and write a plugin for it which will support some or all of the Ruby escape characters.

I'm happy to tackle this soon as I am aware that format validation in Judge needs some work. Tokenizing is a bit of a glaring omission too, for example. :)

For now, my advice is to either change your server side regexp to use ^ and $, or keep on using your forked version of Judge – whichever you feel most comfortable with.

[ghost]

Hi Joe.

Thanks for your quick answer.
We will carry on with our fork for now, but I completely agree with your point of view. We have been discussing about the issue you're talking about and decided that replacing these two characters should cover at least 80% of the needs (usually ensuring that an expression stays only on one line).
But you're right saying that it should be fully generic and relying on a specific project managing these differences.

I would be happy to help you integrating the solution you're talking about if you need.

Finally I'd like to say that we really like this Gem which is really useful and of great quality.

Thank you for your great work.

Yann for the Silicon Salad Team

[joecorcoran]

I'm glad you guys agree. Thanks for the kind words! I'll try and remember to give you a shout when I've started on the XRegExp integration.