Re: Thoughts on QuickForm-additions (again)
| From: | Tomas V.V.Cox | Date: | Wed, 27 Aug 2003 14:58:56 +0000 |
| Subject: | Re: Thoughts on QuickForm-additions (again) | ||
| References: | 1 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-20642@lists.php.net to get a copy of this message | ||
On Friday, August 15, 2003 18:29, Bertrand Mansion wrote:
> <paj@pearfr.org> wrote :
>> On Fri, 15 Aug 2003 17:25:43 +0200
>> "Stefan Neufeind" <stefan@neufeind.net> wrote:
>>
>>> 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!
>>
>> FYI, Bertrand asked me awhile ago to alter Validate to make its life
>> easier to integrate Validate support in HTML_Quickform. After a short
>> discussions, I did the required changed and set a new way to pass args
>> in Validate. He asked that for the next major HTML_Quickform release. I
>> expected 3.O was this one, but it seems not ;).
> HTML_QuickForm can already work with Validate without problems, thanks to
> the changes you made that I indeed suggested a while ago. The documentation
> explains how to use it.
> Now I would just like to end this discussion. Everything proposed here by
> Stefan is out of scope and does not fit into the plans we have to improve
> validation into QuickForm. That's the reason why I suggested Stefan in the
> first place to use a regex and custom functions for your number validation.
> Validation is working fine in QuickForm, we are just thinking about moving
> it out of the main class and at the same time optimizing the process while
> keeping BC. This task requires time to choose a good solution.
> The proposed integration with Validate will require even more time and I
> don't have enough available right now, plus I don't like the way Validate is
> now.
> At the moment, Validate is only an unorganized collection of methods that
> don't need to interact with each others. It could as well be a collection of
> functions, there is no need for encapsulation or any other OO features. I
> find the concept a bit stupid, you can't keep on endlessly adding methods to
> the main class, it makes it bloated, useless, heavy.
> Usually, when you validate your data, you just need one or two methods.
> Validation methods should be organized by topics, types or whatever into
> smaller classes. A main array should tell the main class where to find the
> requested methods and load the file on demand.
> And looking at the strategy pattern could also be a good idea for everything
> related to validation.
I originally coded Validate, with two requirements in mind:
1) Has to be able to validate data comming from common web forms
arround internet.
2) Has to be extremly simple, fast and easy to use.
In php it's better to just add lines to a single file than include
different files, even if they are small. The methods there aren't
"unorganized" as you think. Most frecuently used methods belongs to
the main class while the rest are loaded on-demand. If there are some
not-so-common methods inside the class is for the reason I told you:
no sense to include a file with 10 lines of code.
I bet you that only with number(), string(), email(), url() and date() you
can validate 90% of the forms in the www.
The Strategy patter you mention, looks for me as a "how to bloat the
code with no benefit" solution. Man, having to code a 50 lines class
just for validating a password is just crazy.
--
Tomas V.V.Cox mailto:cox@idecnet.com