>> Using my Field plug-in (http://jquery.com/plugins/project/field) you
>could
>> do:
>>
>> $("#id_cliente").setValue("2");
>>
>> The big benefit to using my Field plug-in is that you can change the form
>> field from a select box to a checkbox or radio element and you would not
>> have to refactor code that grabs/sets the value of the field.
>>
>> -Dan
>
>Dan, that truly is an advantage. But I was of the opinion, that val()
>works with selects and radios as well, thus the refactoring possibility
>exists for core jQuery as well (of course I don't want people to stay
>away from your plugin by saying that).
I don't believe val() is 100% cross-browser compatible for select elements.
val: function( val ) {
return val == undefined ?
( this.length ? this[0].value : null ) :
this.attr( "value", val );
},
The code only works if the element returns a "value" attribute. This might
work in most modern browsers for a select-one element, I'm not sure what the
behavior is for a select-multi element.
Also, my getValue()/setValue() methods work with checkbox and radio elements
(well, every field element--the only exception being the setValue() on
read-only elements.)
>Another question (Mike, Dan?). What are the differences between form and
>field plugin?
The Field plug-in is basically a companion/stand-alone to the Form plug-in.
You don't need Mike's Form plug-in, but it works great in conjunction with
Mike's code.
My plug-in is geared towards reading and manipulating the form fields
themselves. Methods such as the formHash() make it really easy to populate a
form based upon a JSON packet.
It's also the first jQuery plug-in that allowed both getting and setting the
value for all form field elements.
I'm also working on adding addition useful form-based UI methods. I just
recently added limitSelection() (allows you to limit the number of
checkbox/select elements that can be selected) and createCheckboxRange()
(allows you to [SHIFT]+click to highlight a range of checkbox elements.)
-Dan
