> Know your data, if you know the types of data you'll be using you can > avoid collisions.
Look, just use a proper, reversible encoding. :P "Know your data" in this case would need to extend to all values that could ever populate a dropdown. I work in different data domains and I've never encountered a constraint like "new values may have any unique combination of characters and whitespace, but must also be able to have a unique yet non-random alias with whitespace completely stripped that may be losslessly back-referenced to the full value by a human developer." That kind of constraint at any kind of scale is crazy! > For the rest of your comments, I'd say they sound a bit academic. I admit they are optimistic, but they apply to the real world. There are millions of devs in control of both client and server side of their projects. I don't know what the proportion is on the Moo list, but if you check other client-side lists you can see that that the jQuery-Apache-MySQL-PHP "stack" used by solo devs or a cooperative bullpen of 2-3 is commonplace. Asking a PHP question is seen as just the flipside of JS. Newbies abound, to be sure, but they are writing their own newbie server code alongside client code. I don't see any reason not to encourage leaner, less clunky field submission just because some server APIs are hardened or some server devs are walled-off or uncooperative. Do we tell people not to learn bitfields at all because legacy back ends are likely to use individual flags? Don't bother trying to keep GETs safe because lots of existing (and enduring!) server code doesn't respect that rule? I don't see any harm in communicating... maybe people will help build better stuff when they get the chance to build from scratch. I take myself as an example. My old server code is shite; the newer stuff better and the client code is better to match. If I didn't think, "Is there a better way for these two to get along?" then I would still be building for a back-end as bad as my worst work. -- S.
