Re: Thoughts on QuickForm-additions (again)

On 16 Aug 2003 at 14:29, Alexey Borzov wrote: > 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... Thank you for the point :-) > > 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 do. But I'm thinking of how to introduce this into QuickForm/Validate since this might need some really big changes and also brake parts of the API. > >>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. Sure. But Bertrand and you said that QuickForm is "bloated". Or was it just Bertrand? Anyway: I think he meant that no more validation, regex and stuff should make it's way into QuickForm but the existing should be moved to other classes (like Validate). > > 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. Hmm - but again this is not possible at all without braking the current API - or do you see a solution. And we can't break the Validate-API. > > 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... :] You surely know this is not possible. And talking again about a "ValidateAdvance" or "Validate2" or something is not a good idea either. Pierre is open for changes as long as they are reasonable and maintain BC. So do you have any suggestion? > > 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. Generally you're right, yes. But why can't you use both for the moment? I think of having an OO-validator as a wrapper for procedural validation-routines. This way we could integrate new OO-validators and at the same time use already existing validators (that are used by projects already) from Validate. > >>QuickForm itself is a huge overkill, building forms by hand works > >>*much* faster. > > That was intended to be ironic. Oh, good that you pointed that out. Thought you didn't like QuickForm anymore and changed mind. Sorry I didn't get your ironic - but there was no grin or something at all. And since I'd like to find a solution I'm looking from a more technical than "funny" point of view. > > 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. Good then. Well, and how can we make it even better? I think we should do changes to the validation-part to allow even more ways for validation (server *and* client side) "out of the box" (distributed with QuickForm / Validate / ... and not "you can surely write your own validators in your app if you have need"). Back to the example: minValue and maxValue are in my view quite vital - but can't be implemented using regex. > >>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: > > > > ¢pU.º[dF`2ïY7ä > > 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. Didn't get that point completely. Could you make the different ideas maybe a bit clearer? Is it something on which you already decided or is it for discussion? And why do API changes (do you mean extensions - or your "rewrite" mentioned above) break anything? > As for the client side, I'd like to see some actual code before saying > something. That's another open point. I guess we should base it on the "whole validation infrastructure". Meaning that if we decide to move things forward to use Validate, maybe do extensions to validate etc. we can talk about javascript-validation as well. At this point in our designs / additions / changes for Validate we should keep in mind that we need to consider JavaScript also - meaning: An open design. But I can't yet propose any "actual code" till the general things about Validate etc. are not ironed out. [...] > 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. Excellent. So you already have plans? Or is it good / helpful that we discuss validation-integration a bit further on this list? I guess we should also talk to Pierre since it's his Validation-package and he is also familiar with HTML_JavaScript - which can / should be used / extended for the client-side part. I don't necessarily need to be involved in this part of discussion. (If it's public I'll try to take part if I can / find the time.) But I hope you will discuss the validation-aspects with Pierre. Just keep in mind that it doesn't help anybody if you say "Validate is bad", "we need to completely rewrite it" and on the other hand "no I don't want to change a thing". Pierre is open-minded for reasonable suggestions / enhancements. And I think this is the way to go. > > 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. That's how I got it. Not add it to QuickForm itself but maybe to Validate. And therefor we might find a way towards better validation- integration (including client-side). > 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. There was no flaming neither involved nor intended. The discussion was mainly about concepts, how work can go on and even how Validate and similar packages can work together. So at the moment it was a general remark asking "where could additions like this be done". I'm sure you do your work and think of various ways. Just make sure you *talk* to somebody and try to find good solutions ... not taking it to "political" and fearing with people. As Bertrand said: I want to end the discussion (my discussion) at this point. Stefan