Mike Alsup schrieb:
I would opt for a new method name so that
existing methods can be deprecated and eventually removed. This is
why I'm not a big fan of overriding "val". I think it's too ingrained
at this point and a behavior change would be trouble. Even though the
return type would be the same, the return value would not (or might
not).
Overwriting core methods is fine as long as you don't change the
contract/behaviour of that method. Just think of a site that uses the
form plugin and a different that relies on the standarf val() behaviour.
An extension that can handle arrays to manipulate selects/checkboxes
would be fine from my perspective.
2) If you use an array to set the value on a text field, what value
should
we put in? Only the first position? Do we concatenate the array and
use that
value?
Good question! :-)
I can't imagine a case where I'd have one or more text inputs and an
array of strings and want to map one to the other.
I'd probably start w/the methods that manipulate select elements (moving
option elements around, transferring them to another select element,
doing
n-related select boxes, etc.)
Yes. Sam Collett has some great option utilities as well, and they're
already jQuery plugins. That would be worth looking into.
By merging those plugins/efforts a lot of duplication could be avoided.
Modify the form plugin to handle all the generic manipulation stuff and
provide plugins on top of that to do special stuff like what Dan mentioned.
--
Jörn Zaefferer
http://bassistance.de
