Base regex rule style for improved flexibility about treacherous HOT 5 CLOSED

Only problem here is that this rule would need the user to explicitly add it into the rule registry so to even use this rule class you would need to do more than just including treacherous, which makes it a custom step and although this placeholder style rule would be useful for people it may not be useful to all.

So I am in 2 minds if this should be seen as a possible enhancement, so it can be consumed by others if they wanted to have more complex regex rules without having to write custom rules, or if it should just be down to user preference to do the above, as you can already do what you want above in the system via the existing regex objects its just you would put the regex into the options when defining the rule rather than pushing it up to the registry level.

Can can discuss it further but I see that for the majority currently this would not add much benefit as the amount of times people need to do regex the current regex rule would be applicable, and if they have complex regex rules they could easily just create a custom rule like you do above, as once you start to open up blueprint rules like above where do you stop?

Anyway lets chat and see what happens.

from treacherous.

Yes, hence the examples at the bottom explaining two ways of adding it with a custom message.
If every rule is responsible for its own message, as it is at the moment, then for the user to add custom re-usable rules with associated messages then they either have to be added to the central registry or you have to add a local registry against the validationGroup.
In this case, in my code I add rules of "domainURL" that does not allow a path on the domain name but requires a trailing slash, and "domainPage" that allows a trailing path. I use the first in one input field, and the other in another three, so in the absence of custom messages per field (and as a possible alternative) this works adequately.
Perhaps a fluent syntax to add the rules would be nice, as this makes adding custom rules a first-class citizen rather than a low-level fallback when you realise the default rules don't suffice.
I think that having a registerRule on the validationGroup that is used in preference to the global rules would be prefereable, as this avoids having to find unique names for every form's field's requirements.
Also, having the option of a method for resolving the name allows more snazzy messages if the dev decides the user needs them, yet adds nothing to the complexity if they don't need it.
The issues with using options to pass in all your parameters are:

1. You have to duplicate fields such as regex if you have many similar fields (URL matching for example)
2. You can't change the error message on a per-field basis unless you code that into the rule parameters
   The advantage of predefined generic rules is that they save you typing, but the disadvantage is that alterations have to be implemented somehow, and generic options structures get unstructured difficult to follow very quickly.
   Perhaps some of this is related to using string for rules. You can't specify parameters nicely when using strings, so at least this rule-builder method allows strong-typing, and an unlimited number of configuration parameters the could be bound to the options in addRule if necessary (have to think about that one)

from treacherous.

Given the conversations we have had on the matter and with the ability to add custom message overrides (via #12) what are your current thoughts on this?

from treacherous.

The need to do this for custom messaging is now removed, but I see no issue in providing simple helper base classes for when a developer needs to create a custom rule, primarily those that are regex or Promise based.
Even the current email, number, date and iso-date are identical except for the regex expression, so they could be removed and replaced with calls to RegexBaseValidationRule or whatever a good name is in the exposer.
I'd simply suggest there be a helper function to make life easier for people to build their custom rules. The benefit is that a single line in the doco can be used to demonstrate creating a custom rule with a complex regex (which is probably the most common custom-rule usage scenario), rather than having to create new classes where 90% of the codebase is common.

from treacherous.

Added to next release, although it is called AdvancedRegexValidationRule and added some error catching to the constructor.

from treacherous.