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

> -----Messaggio originale----- > Da: Justin Patrin [mailto:papercrane@gmail.com] > Inviato: domenica 26 marzo 2006 11.48 > A: Giuseppe Dessì > Cc: pear-dev@lists.php.net > Oggetto: [ok] [PEAR-DEV] 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. > Oh yes!! I agree with you! My question was a doubt not a proposal ;) About this DHTML implementation i think it's a beautiful method! More more userfriendly than the standard! I think i will use it. Good job ;) bye