Re: Thoughts on QuickForm-additions (again)

Hi! Stefan Neufeind wrote:

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

We're not talking about huge JavaScripts at the moment. But about soem verifications that can't be done with regex. There may be a "JavaScript-repository" but I guess in our case it should be consistent with the serverside-validation-functions - otherwise we might run into problems.

You have a point here, indeed. And now I see that it integrates quite well into my hypothetical Validator classes...

So you think that the patterns-concept (which looked quite like an overkill - as stated before) would be "useful" to validate a decimal number or something? Even more useful than writing the three lines yourself? Well maybe we should discuss the use of phppatterns for more things then ...

Are you familiar with design patterns concept? Yes/no, please.

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

But the thing that it's not OO is good in my eyes. The class would get *really* bloated if you had an object for every validation (and be it even validateNumeric or something).

No, we will have several small classes instead of single bloated one.

And being it no class at all would be bad either. But having to instanciate a $vali = new Validate(); if ($vali->validateNumeric(2)) Would surely be "out of the bounds", right?

No, as you will just instantiate the class, its validate() method will be called automatically by e.g. QuickForm.

So assuming that you don't have something personal but technical that you don't like about Validate and reminding that you already proposed changes that made their way into Validate: Why can't we then discuss an extension of Validate right now?

Clarification: it was Bertrand who made changes to Validate, not me. And changing Validate to implement Strategy pattern is not an 'extension', but a 'complete rewrite'. We can discuss this, of course... :]

Well you can't do it with new. But why can't you just give it a string/name pointing to a function like in: $form->addValidator('field', new ValidatorRequired('Field is required', 'Validate::creditCard')); Or similar? If we intend to rely on Validate I think this might be a way to go. Or maybe put the "Validate::" into a separate string because then we can also call 'Validate_JS::creditCard', which surely won't do the validation but return the script-code.

Callbacks are for procedural programming, we are trying to do OO here. Besides, a Validator object can have variables, like an object for DB/LDAP/whatever access. It is more flexible.

QuickForm itself is a huge overkill, building forms by hand works *much* faster.

That was intended to be ironic.

If you say "bloated" because you mean the code - okay - we can extract some parts and put them into Validate or somewhere. But for the rest I blieve QuickForm is fine and gives nice, consistent results for "quick form creation and handling". Will/Can your aversion against HTML_QuickForm be solved somehow? Or what will be the consequence? I for my part like it and would love to see it developing/improving.

I have no "aversion". I use QuickForm myself and it *is* a good instrument. And I *actually* write code to make it even better.

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

But he also pointed out that "you need to integrate Validate via a custom function" for this and that "for client-side validation you need to provide a separate javascript-function in your page". How do you want to integrate Validate-functions in QuickForm? Having a look at: http://pear.php.net/manual/en/package.html.html-quickform.php the only solution seems seems to register a new rule via "registerRule", right? Or are there other ways to do it (better) that just aren't in the docs yet? And how about the client-side?

Yes, and there were 2 proposals to make this registering automatic: 1) Doing registerRule() on Validate.php include like is done in HTML_QuickForm_file 2) Adding introspection API to Validate so that functions can be registered from within QuickForm Automatically registering Validate's methods within QuickForm without introspection API is not a good idea: you'll have to make changes to QuickForm each time Validate's API changes. As for the client side, I'd like to see some actual code before saying something.

For sure you can provide your own JavaScript-source for validating e.g. decimals but if you have the German 2,5 and need to convert it to 2.5 (could be done automatically via the locale settings of PHP) and then validate it against min and max values I don't think this is a thing for which everybody should need to reinvent the wheel everytime he needs it. This was the basic intention about raising any discussion about this topic.

Got your point.

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

If you got that wrong I'm sorry - wasn't intended. But Bertrand already explained that there are things that he doesn't like about the "bloated class" and that unfortunately there is too few time at the moment. I surely wouldn't say that I'm an expert in QuickForm but have worked with it for quite a while now and digging up the code for functions that aren't in the docs right now or need further explanation than is in the docs. To me it just seemed that raising a suggestion ended in a strict "no" and "do it by hand on your own in the program" without allowing any discussion that "this might be a good point" and "unfortunately we've decided to first do ..." or a concrete solution how to help.

Just to let you know: we are right now designing the new package which will build upon QuickForm and add some new functionality to it.

Hoped to get this discussion a bit further - maybe to talk open about development, plans and maybe discuss various possibilities in the public. But it seems you already found your way for the ongoing process but currently lack a bit of time. Well I won't bother you again with this one if that's what you want and will wait for the final whistle saying "we're done with the changes - and now you can do your stuff this or that way". Hoped to find an open discussion with you about colaboration - but maybe it's easier for all that *you* go on with *your* work and that we all wait and see what comes out.

I hope we were clear enough why we don't generally want to add new features to HTML_QuickForm class itself? But we do gladly accept proposals and contributions, just look at the CVS logs. If you want to collaborate --- fine. Write some code (or better yet, write some docs :]), you may even post it to the list to initiate further public discussion. But flaming with package developers while *not* having any code to propose is not my idea of collaboration, sorry.