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
