Know your data, if you know the types of data you'll be using you can avoid collisions.
For the rest of your comments, I'd say they sound a bit academic. Most development situations are different and unless you are developing from the ground up Client/Business/Data layers where you can control majority of the environment, you'll be faced with the usual legacy code/data, past development efforts usually by a host of different developers each applying their own structures and standards, alongside the actual data in the database. In most cases you'll have to work with the data/values that have already been defined (right/ wrong) and make the situation work. On Jun 12, 3:32 pm, Sanford Whiteman <[email protected]> wrote: > > This is what I have done in past. > >http://mootools.net/shell/UZ4TF/ > > Hey, you're going to have some collisions with that workaround (like > 'ab' and 'a b' are both tamed to 'ab')! :) Something that is two-way > like URL-encoding would be a better approach. Also should use HTML > data-* as the attribute name so this would potentially validate. > > But, back to the OP, I have to suggest there is a less-than-best > practice underlying this problem, even if there is also a bug in Moo. > > IME, the `value` attribute on option elements is usually a "magic > string" that should be replaced by a numeric index. Most of the time, > the value is initially (or should be) drawn from a database or at > least a separate array either on client or server. There's no > situation I can think of when both option values and text must *only* > be defined in the markup. Just because the corresponding value is > known at the time the option is drawn doesn't mean you need to write > it all directly into the document. > > When you use numerics for your possible values, a great advantage is > server-side validation. Just cast to an int and make sure it's within > the known length of the array and nothing unwanted can sneak in. You > don't need to escape any strings nor re-match them to the allowed > picklist. A second advantage is bandwidth: you don't have to pass any > "friendly names" back across the wire on the form post. Third, I > think, is clarity: a distinct client- or server-side array is much > easier to read than picking data out of the markup, and as noted, once > you have an array, why would you also copy it wholly into the markup? > > I'm not saying it isn't convenient and sometimes necessary to copy the > values inline, but I think that is a practice that deserves some > scrutiny. > > -- Sandy
