Re: Thoughts on QuickForm-additions (again)

On 15 Aug 2003 at 19:03, Alexey Borzov wrote: > 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. Maybe at the moment - agreed. But we could "invent" a general api for validations - that can do even more than regex. > > 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? 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. > >>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) 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? 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? > > 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? ;] 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. 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! Stefan