Re: Thoughts on QuickForm-additions (again)

Hi! Stefan Neufeind wrote:

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

Thought about moving that into Validate also, and JavaScript being returned by the function mentioned above. Another solution would be to have a separate JavaScript-file that can be loaded into the page where you need validation. On the one hand this would be a good solution since you can then use the same functions in every page without reloading any JavaScript- code. But for small sites you would always require to load the full JS-"library" even though you don't need special features / functions. Another bad point about keeping it in a separate JavaScript-file would be that you can't access it via "http://webserver/html_quickform.js" or similar - because it's part of pear and doesn't reside inside the www-tree. You could copy it there ... but this would disallow any changes to the javascript-files since people would forget to copy the file again from the pear- directory to the actual location from where they load the js-file. So returning JS from a function would be the best solution I can think of. You could also generate that JavaScript as a whole at the time the form is actually drawn in HTML. This would be possible if you parse an array to the function getJavaScriptValidationByName containing all javascript-validations that will be used in the form. This way getJavaScriptValidationByName could avoid duplicate entries and maybe at some point even optimize the JavaScript-code :-) Other proposals welcome.

No proposals, but a comment: PEAR means 'PHP Extension and Application Repository' not 'JavaScript ...'. Which also means that a dedicated JS repository may already have some validation functions that can be used in QuickForm. And the infrastructure is already present for this...

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)

What do you really hate that much about Validate? What for do you need an "OO approach" for a call like "validateDecimal (2.5);"? This seems contraproductive in respect to the Validate package in my eyes. Sorry don't have time at the moment to look into phppatterns THAT deep. But isn't this a bit too much of an overkill?

Fortunately for you, phppatterns.com does not quite work right now. Else I wouldn't waste time writing this. I don't "hate" anything about Validate. I just said that it does not have an OO design: it is a collection of functions grouped in a class (as PHP lacks namespaces). As for the difference, consider $form->addRule('field', 'Field is required', 'required'); $form->addRule('field', 'Field should be numeric', 'numeric'); vs. hypothetical $form->addValidator('field', new ValidatorRequired('Field is required', new ValidatorNumeric('Field should be numeric'))); In the first case we have validation logic (like if the field is not required and is empty then it is valid, if the field is required and not empty then we perform further validation) and error messages in the main class. The validation functions are 'stupid', they just return true or false. In the second case all validation logic is inside Validator classes. QuickForm itself is a huge overkill, building forms by hand works *much* faster.

And in addition: If we really might want to use phppatterns via Validate (or without) in HTML_QuickForm this would require to discuss adding phppatterns-classes to pear as well, right?

Not right. Phppatterns is not a code repository and there is no actual code there, just some examples.

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? ;]

I'd like to improve HTML_QuickForm by minValue and maxValue as well as the ability of client- and server-side-validation for decimal numbers. Since this was rejected due to a "too bloated" HTML_QuickForm and would fit well in Validate I suggested we move all validation-parts to Validate, extend them and make them extensible.

QuickForm can work quite well with Validate now (as Bertrand already pointed out), thus no changes to QuickForm are required for this. How fortunate.

This way Validate would profit, HTML_QuickForm would profit and HTML_QuickForm would be able for further improvements in some areas - a thing that seems to be really stalled at the moment ... which seems contra-productive!

ROFLMAO Are you *that* familiar with QuickForm development to call it stalled?