Re: Thoughts on QuickForm-additions (again)

Hi! Stefan Neufeind wrote:

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.

In fact, QuickForm does not contain any validation functions right now. It does contain infrastructure to do regex checks against fields, but the size of it is insignificant.

Is that I good idea? I'd implement client-side and server-side- validation similar (like getJavaScriptValidationByName('numeric') returning a JavaScript or similar).

You didn't answer my question: where will this javascript be kept?

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).

In fact, I don't like Validate package that much. The functions are good, the design is not. I'd rather see a more OO approach, maybe implementing Strategy pattern (see phppatterns.com for a description)

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?

I don't completely understand you: you want to make some proof-of-concept stuff yourself or you want the packages' developers to get up and start coding? ;]