Re: Thoughts on QuickForm-additions (again)

On 16 Aug 2003 at 17:27, Alexey Borzov wrote: > Stefan Neufeind wrote: > > 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. > > Well, as Pierre helpfully pointed out, Validate is still in alpha. The > PEAR definition of alpha > (http://pear.php.net/manual/en/faq.unstable-code.php): > > "early stages of development, all things could change (API, behavoir) > without notice, expect lots of bugs" > > So we can break the API of Validate as we like. Well okay. But only if we have a good concept :-) > >>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. > > Yes, Pierre is a very nice guy. I had enormous pleasure collaborating > with him and proposing enhancements to the package he maintained. I am > glad that you get along so well and hope that your help will be a > great boost to Validate's development. This the Pierre I got to know up to now, yes :-) > > So do you have any suggestion? > > Yes, scrap it and start over again. Hmm, have some other things to do / commit first. But then I'll come back to you - now that all "misunderstandings" have been cleared. If they mainly came from my side please excuse. > > 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. > > We can use them *now*. No need to bother with wrapping. As stated above: with good concept okay. It seems you already have an idea "how you want it to be"? If yes, please show us, then I will discuss the possible / necessary changes with Pierre and "do the rest" (if he agrees). > > 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. > > It is already possible to do minValue and maxValue using > Validate::number() Haven't you looked at it? Didn't yet find a way to "registerRule" a Validate::nuimber() :-) But will have a look, promise. If it's just one line or two maybe you can help me out? [...] > >>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. > > I am not talking 'final' implementation. I am talking > 'proof-of-concept'. Now show the code. As said: Don't have have code yet but in a first step tried to "mediate" between the involved parties because I felt there were some "barriers to cross". Maybe they were merely caused by misunderstandings. If you have already got (half-)concrete ideas on how this might be done (API, integration) then please let us know. I'll discuss this with Pierre then and see what I can do about Validate. > >>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). > > Glad to hear that it has nothing to do with QuickForm for now. Not yet, but it should. Thought of having the same validator-names for Validate and Validate_JS (or what it might be called) so you can easily test if a Validate_JS::something exists and if yes it will return you the JS-code. This is what I meant by "keep in mind during design". Wouldn't that be good? > > 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". > > So you are *not* going to produce code? Read above. Not for the moment. But if we can clear the ideas / API- thoughts a bit more I'd be happy to work on Validate, since Pierre is short of time right now, and do the integration of a new validate with you into QuickForm. Stefan