Re: R: [PEAR-DEV] HTML_QuickForm DHTML client rules and SoftRequired rule

On 3/26/06, Giuseppe Dessì <thesee@fastwebnet.it> wrote: > > > -----Messaggio originale----- > > Da: Justin Patrin [mailto:papercrane@gmail.com] > > Inviato: domenica 26 marzo 2006 9.54 > > A: PEAR Dev List <pear-dev@lists.php.net> > > Oggetto: [ok] [PEAR-DEV] HTML_QuickForm DHTML client rules > > and SoftRequired rule > > > > At the request of a user I've made a QuickForm class which > > alters the client rule system to display errors with each > > field, much like QuickForm's default renderer normally does > > upon submission. (Note that I didn't try to make it > > *perfect*, I was just trying to get it to work > > ;-) It also supports running client rules when a field loses > > focus, its value changes, or a key is pressed. For this last > > to work you have to call getValidationScript() before your > > form is rendered. > > > > The way that this works depends a bit on the normal renderer, > > but a user could easily create divs to put the errors in a > > specific place. > > > > I've also looked again into the idea of a SoftRequired rule > > which makes an error show up the first time a user tries to > > submit a field without a value, then goes away if the form is > > submitted again. I tried before to create this as a normal QF > > rule, which is nearly impossible given QF's limited rule > > system. However, this time I limited it to a client rule and > > it works just fine (albeit with a simple hack to simulate a > > static variable). > > > > This is a good job ;) > But... This is a series of client rule. > How can you make the same with server rules? AJAX? > Doing this with server-side rules would require AJAX and quite a bit more scripting and hacking apart of QF. This works without any changes to QF (well, with an extension which changes the rules a bit). > If this rules are default rules, (e.g: when i set a server rule > automatically a client DHTML rule is setted up) > this is a good idea. > The point of client rules is to run in JavaScript on the client-side. You can choose pretty much any rule to run client-side, but you have to make sure that it's set up for it. All of the default QF rules can work client-side. This code doesn't change any of this, it only allows the client-side rules to run in a more useful manner. Remember as well that rules which are chosen to be run client-side are also run server-side as well so there's no possiblity of the validation being "gotten around" by skipping the client-side JS. Passing 'client' to addRule() is not choosing client-side over server-side, it is choosing client-side *in addition to* server-side. And, on top of all that, AJAX is, by definition, JavaScript. Since there is *already* javascript to run these validations why would you want to add more complicated javascript and PHP code in order to make another server-side call to do the same validation that can already be done with the javascript code? On top of that even, when the form is submitted it has to be validated server-side yet again. Try using the code that I have added and adding the simple 'client' parameter to your addRule calls. It works much faster than and just as accurately as any AJAX you might write. I realize that there are some cases where AJAX *would* help, such as in checking to see if a username is unique, but this is a special case. Simple checks, such as for required elements or a certain formatting can easily be done in straight JavaScript without causing extra server-side processing and extra bandwidth usage. While AJAX is an interesting and sometimes useful technology, since it has become a buzz-word there is a prepondency toward using it for everything, even when it is not needed. Straight JavaScript is still very useful and shouldn't be discounted. -- Justin Patrin