Re: Thoughts on QuickForm-additions (again)

On 15 Aug 2003 at 14:09, Bertrand Mansion wrote: > <borz_off@cs.msu.su> wrote : > > > 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. Ooops, please believe - I didn't do it intentionally. Sorry for that! > 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. Well, should we really consider moving regex, server-side-validation and client-side-validation to Validate? I guess Pierre would be happy with that addition - I'm almost deeply sure. This would mean that HTML_QuickForm might shrink a lot / a bit. My proposal would be to have functions in validate that as a basic step serve HTML_QuickForm with all validation needs. Surely the interface of HTML_QuickForm needs to stay BC - but I don't see the problem. We could even add a function "validateStringByName" or something that might get called like validateStringByName ('numeric','12938') and return if the value is correct. This way we could arrange for complete compatibility with the current HTML_QuickForm-API, will shrink HTML_QuickForm just to the parts for actually calling Validate- functions and everybody would be happy. Is that I good idea? I'd implement client-side and server-side- validation similar (like getJavaScriptValidationByName('numeric') returning a JavaScript or similar). > >> 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. :) So what do you think Bertrand and Pierre? Would moving this to Validate be a good idea? If you agree please let's start a discussion on which interface-functions would be best (naming and functions). > > 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?log > > in=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 ? That could also fairly easy be done, yes. Having a lookup-table for these get...ByName-functions which could be extended at runtime like you already implemented it in HTML_QuickForm. Any drawbacks in this proposal? In my eyes it seems like an open discussion on the mailinglist helps more than hiding behind short "no, I don't want to add this to the class"-mails. If Pierre agrees to add things like this to Validate we might very soon start moving, right? Please feedback :-) Stefan