Re: Thoughts on QuickForm-additions (again)

<borz_off@cs.msu.su> wrote : > Hi! > > Stefan Neufeind wrote: >> Hmm - again seems like some topics are simply being lost on this list >> these days. Well, maybe there has too much discussion about the >> "secondary maintainer"-thing and similar topics so that some people >> simply stoped listening. >> >> But I'd like to try again and politely ask for your comments on this >> proposal to QuickForm > > Usually lots of people will pop up telling you that starting a > discussion/vote about adding something to a package that is actively > maintained is not the PEAR way. The maintainer has to decide. > > Unfortunately these very people have some personal disagreements with > QuickForm's maintainers so they keep their silence in this particular > case. ;] > >> In detail: >> a) one example of such a regex allowing 0, 1 or 2 decimals would be: >> >> /^(([0-9]+)|([0-9]+\.[0-9]{1,2}))$/) >> >> The dot in this example could automatically be adjusted to fit the >> locale setting of php, which might make it quite handy. Bertrand >> responded to use registerRule during QuickForm-runtime to register a >> new rule for this. That's something I intended to do for the moment. >> But the basic idea was if numbers with up to two digits are commonly >> used (e.g. for quantity or monetary values) and if such a type might >> be a general enhancement so people don't need to find that regex >> themselves, but can assume it just exists. > > I don't really know why Bertrand objects to adding the new regex to the > package, but he may have his reasons. First, I hate when people call me Bernard, it happens too often. But really, I don't think QuickForm is the right place to store a regex library. It was a bad move to add some at the beginning. They belong to Validate or any other validation package and now I would like to limit their additions to as few as possible. We already had to change the nonzero rule for some reasons. The same could happen very soon with the proposed regex when users will notice it doesn't validate numbers with commas, spaces, minus sign, currency char, and so on. >> b) Currently there are minLength and maxLength refering to string- >> length, which can easily be implemented via regex. This is however >> not >> possible for minValue and maxValue refering to the numerical value. >> Bertrand pointed out correctly that it possible to write your own >> function for server-side-validation of a numerical value and that if >> you supply a JavaScript-function on your html-page with the same name >> this function would also be used for client-side-validation. I just >> thought having minValue and maxValue in QuickForm might be a good >> idea >> so that people don't need to write 2 functions (server-side and >> client-side) on their own, since I believe these value-bounds are >> also >> commonly used. Another point that doesn't make comparing the value >> entered in the form with a min/max-value that easy is that in e.g. in >> Germany a comma is used as the decimal point. For validation with >> JavaScript this would have to be converted to a dot before >> comparisons. The same applies to server-side. For the server-side >> validation Bertrand proposed to use the Validate- package which, as >> he >> said, already handles locale settings for the decimal separator. > > QuickForm right now doesn't have a place where JavaScript validation > functions might be kept. Where do you want to keep yours? > As for server-side, we are trying to reduce the bloat, which will mean > removing some of the functions from HTML_QuickForm, and you are > proposing adding something to it. Would be nice to have a javascript validation package in PEAR. :) > If Validate already provides this, then I have a proposal: why don't you > contact Validate package maintainers and ask them to add automatic > registering of validation functions if HTML_QuickForm class is found. > Look at HTML_QuickForm_file for a reference on how to do it: > > http://cvs.php.net/co.php/pear/HTML_QuickForm/QuickForm/file.php?login=2&r=1.1 4 That would be nice actually. Maybe we could also go the other way around. Or ask them to provide some kind of introspection mechanism that could let other classes know which validation methods are currently available ? Bertrand