Re: Thoughts on QuickForm-additions (again)

On 16 Aug 2003 at 10:32, Alexey Borzov wrote: > Hi! > > Stefan Neufeind wrote: > >>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. > > 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. Pierre said he's looking into extending HTML_Javascript a bit further and that Validate might call features / functions from HTML_Javascript to correctly return JavaScript-(client-side)- validation-functions. I guess that might be a way to go. > >>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? > > Fortunately for you, phppatterns.com does not quite work right now. > Else I wouldn't waste time writing this. "Fortunately for you"? Are we already getting into some kind of agression? Didn't intend to but ... 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 ... > 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). 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? 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? But keep it an open discuss. If people say "well no, I guess it's good as it is now" don't go "but I still don't like it - so I would do anything in this subject". This is a place of colaboration. And if we come to a point where we say that other things need to be done first before other changes can be made that's fine and logical. But we shouldn't sit there and cry ... Got the intention? > $form->addRule('field', 'Field is required', 'required'); > $form->addRule('field', 'Field should be numeric', 'numeric'); > > vs. hypothetical > > $form->addValidator('field', new ValidatorRequired('Field is > required', new ValidatorNumeric('Field should be numeric'))); 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. > In the first case we have validation logic (like if the field is not > required and is empty then it is valid, if the field is required and > not empty then we perform further validation) and error messages in > the main class. The validation functions are 'stupid', they just > return true or false. In the second case all validation logic is > inside Validator classes. As said above having these many classes and having them just for validating a numeric or something doesn't sound the best solution to me. What's so bad about true and false? E.g. the new Validate_IBAN (which will be added shortly) can be accessed directly as a separate object OR be called via the validateIBAN just returning true or false for "quick validation" as Pierre said. This seems an extensible way. > QuickForm itself is a huge overkill, building forms by hand works > *much* faster. If you take good validation, functions like freezing etc. into account QuickForm is quite handy. But I didn't think that I needed to promote the class to one lead of HTML_QuickForm. It seems that you and maybe even Bertrand are not really satisfied with HTML_QuickForm. 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. > > 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? > > Not right. Phppatterns is not a code repository and there is no actual > code there, just some examples. Okay. As said, didn't yet have time to read. Will do. But I don't think this helps us much with the current issues that need to be discussed. > >>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. > > 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? 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. > > 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! > > ROFLMAO Could we take it a little less agressive? > 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. As Pierre said he implemented your suggestions in Validate already. And if it comes to Validate_JS or whatever I'm surely he'll be the last to deny extension / discussion about that. 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. With a sigh Stefan