Yes, \W \D & \S are all the same in PHP too. I'm no expert at all on this but for the most part, I believe that PHP and JS regular expressions are pretty compatible but, for cases where they do differ, you're right - 2 sets of rules would work perfectly!

Thanks again for all the help! Especially when I know you must be super busy working on 2.0 production which I know will be absolutely awesome! Cant wait!!!

Thanks Jocelyn!

Best wishes,

Gez

Hi @admin,

I'm really sorry but I'm afraid that upon further testing of this, there are some other issues.

Basically, when I re-installed my component last night after commenting out lines 54&55 of the validation helper, I tested only the validation of my decimal field in my product layout. As I said last night (or early hours this morning), it worked fine in that, if I entered values that were too long or too small, jQuery validation was kicking in to say I had an incorrect value - AWESOME! However, there is a very strange anomaly; after importing all of my inventory, categories, sections and products - data that is dependent/required in the form - I now get issues where entering a price of 20, 20.00, 123,123.00 ...123456.00 are all deemed invalid.

Also, upon saving the record, I now also get invalid boolean values on a not-required field to specify whether this product is the default or not.

I have re-tested this on another Joomla installation without any of the related data loaded as I tested for you before closing the ticket and the behaviour was exactly as I described - 0.1, 123456.00 ... 999999.99 all validate correctly and decimals out of this range invalidate correctly.

So, what is different?
Well, as I said, the only difference is that when I have dependent data loaded, it does not work. The fields that I have on the layout are:

• Title - String/Varchar{0,255}, Required
• Alias - String/Varchar{0,255}
• Image - Image uploader, Required
• Item - FK to inventory grouped by Section (Title), Category (Title) - These are the related items that I mentioned
• Price - Decimal(8,2), Required with my custom regex

  //Handler: price8prec2scale
  ^(0?(\.(0[1-9]|[1-9]\d{0,1}))|[1-9]\d{0,5}(\.\d{1,2})?)$

• Default - Default wizard (undefined default value)
• Published - publishing wizard

This is very strange behaviour indeed and I cannot see where the issue is caused.

1. Are there any reasons why commenting out lines 54/55 of the helper should cause an issue for the other fields?
2. Why would having data loaded in my FK effect the behaviour of the validation in this way?
3. Could the default or publishing wizards causing this?

Please could you take a look at this in the sandbox and/or a dev server/

I attach a ZIP of dummy data to load the Secions, Categories, Products and Inventory and I'll also do a quick screencast to further describe the behaviour for you and post that link here.

Part of the message is hidden for the guests. Please log in or register to see it.

Many thanks,

Gez

P.S. I'm sorry this is not resolved! I thought that we were well clear of this!

I can test it for you but please provide me a complete package with dataset inside. I will not import manualy your 4 csv file. If a begin to accept this, I may face such others requests by users.
I mean, I voluntary debug, but it is not included in the service and too much work.

Did you tried again to check the generated JS RegEx ?

Related datas cannot be a problem on that.
Did you flushed your cache ?

But, right now, I can try to add the feature of 2 regExs. This, yes.

Was it working before to comment the lines ?

admin wrote: Thanks Jocelyn!

Gez

Just emailed you at support address subject: Decimal Field Issues

Please let me know what you think,

Gez

I've just uploaded the new feature for you :

in your rule file, you have the protected var $regex, with your regex.
Just under, if you define $regexJs, it will override it for Javascript.

And the 2 lines are reactivated.

Tell me if it helps you..

And the files to upgrade are :
- helpers/html/validator.php
- classes/rule.php

admin wrote: Do you mean reactivate lines 54 & 55 of the validation helper?

Thanks!

Gez

Yes, because I understood your issue was since this change.

So, can you make few tests with or without it ?
And also, you can use regexJs var declaration in your rules files.

No probs!

Will check them now and post back. I'll be 10-15 mins because I need to regenerate, reinstall and re-import the data.

Will post back here as soon as done!

Thanks,

Gez

Hi @admin,

OK, I've restored everything as suggested but still not completely working. If I enter 1, 0.1 - 0.9, 0.01 - 0.09 it validates OK and values save.

If I enter 0.10, 0.99, 1.1, 1.10 ... 999999.99 it says that the number is invalid. 0.01 - 999999.99 are validated correctly in JS when tested at the tester website I linked to before.

On a positive note, it is preventing out of range numbers from saving however, obviously it is not allowing the above in-range numbers to save

Many thanks,

Gez

One other question as I think we might have overlooked this...

In the builder, the built in tester works fine to validate/invalidate exactly what I expect. Is there something else going on here? Are the Regexp's being converted for use with PHP or is something else?

If it works in JS in the builder is there some legacy code to do with rules that's playing a part here?

Thanks,

Gez
*************ADD**************
Also, sorry, I forgot to mention this but, this is one of the reasons I thought that the transformation might be happening somewhere else or in another way... The protected $regex is always the same as my inputed expression. When I copy my original regex into a new $regexJs var, they appear the same:

Hi Jocelyn,

I thought I had this working a moment ago so I deleted what I thought were now 'irrelevant' posts however, I cannot get it to work.

Earlier, when this wasn't working, I changed a few things to debug/fault-find including;
FROM:TO:After lots of back and forth, I finally thought it was fixed so I deleted my posts. As I was posting my findings, I began to remove each newly added block 1 at a time to retest and it all went wrong...

Is there anyway you can restore my deleted posts from the thread?

One of my earlier posts included: Is it possible that we're only having this issue and having to circumvent it with the new $regexJs var/property because of some legacy code in rules or something? I just don't understand how the original regex validates correctly in the builder's tester and on the online tester I pointed to at tools.netshiftmedia.com/regexlibrary/

Can the regex handler use the same code as is used in the builder for testing? This works perfectly in the builder

*********ADD************Currently, with both $regex & $regexJs protected properties set the same as each other as I believe they should be to prevent any replacement of the \d, \w and \s modifiers. However, with this set I cannot validate numbers/decimals that are really in range so, 0.11, 1, 123, 123456, 123456.00 and 999999.99 all invalidate. 0.1, 0.01, 0.9 and single digits are all validating ok.

I've also echo'd "JS' . $regex" inside of the IF statement so that I can be sure that it is using the JS regex and not the regular one. This is working fine and displaying that the field is in fact using the JS regex. Also, I'm flushing cache every time I test so I can be sure that it is not caching the rule in the jQuery validation.

Please any help with this would be massively appreciated!

Thanks,

Gez

notify of edit previous

Also, just to note that I've now returned the validator helper to exactly as you had it: