I remember your n-related selects code back when I first saw you at CFNorth in Toronto. I was in AWE. I'd love to see some robust functionality in plugins for forms. It's an important thing for have for any JS library.
-----Original Message----- From: jquery-en@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Dan G. Switzer, II Sent: Thursday, April 05, 2007 12:46 PM To: jquery-en@googlegroups.com Subject: [jQuery] Re: New Field Plug-in... Mike, >I'd say either make it an option (along with what the join char is) or >just impl two method, one would call the other and then do the join. >Plugins shouldn't feel as constrained by file size as the core. > > >> Strings can be more straightforward (but have certain limitations) >> while Arrays don't have any limitations, but aren't as intuitive. > >True enough, that's why having both would be good. I've been thinking about this well eating lunch (hmmm... Chipotle.) Anyway, I'm wondering if it wouldn't make sense to overwrite the val() method and use that for returning string results. That way instead of having to set whether or not you want to use Arrays or String, you use val() for string manipulation and getValue()/setValue() for Arrays. This leads me a couple of questions: 1) I used the names getValue/setValue mainly because the code is derived from alike methods in qForms. Would it make more sense to use a single method--like fieldValue() (although I'm not sure I like that name?) 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? >> I'd definitely see this as being a good marriage of with the Form >> plug- >in. > >Cool. What other functions in qForm would be good candidates? 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.) -Dan
