More custom field revisions
chicks at chicks.net
Wed Apr 30 14:39:41 UTC 2003
On Wed, 30 Apr 2003, Bradley Baetz wrote:
> On Wed, Apr 30, 2003 at 01:13:49PM +0100, Gervase Markham wrote:
> > You appear to have got a bit confused (or I have.)
> > 37=Bugzilla&... (where 37 is the ID of a custom field)
> Well, field-37, anyway - I don't think that keys can be entirely
> numbers, although I'd have to check specs to be sure.
The name= attribute on <INPUT> is CDATA according to the XHTML DTD, but
that doesn't make a number a good variable name:
1) As Gerv points out this is inconsistant with historical practice.
2) It's nice to have variables names the same across the HTML FORM and in
code. So having the names correspond to Perl's variable name syntax can
make life easier. I can accept that this particular issue may not effect
the current conceptualization of adding custom fields to bz, but it's a
good principle and there doesn't seem to be that much advantage to
3) Debugging these things often includes examining what inputs causes what
bugs and looking at the generated HTML. I'd much rather have a
comprehensible name there than some random number.
4) Moving custom fields between databases would seem to be easier if they
were identified by a name instead of a number. Collisions are much more
likely if every bz install starts with custom field #1.
Except for the third point I don't think any of this is particularly
persuasive, but it's not clear what overwhelms these things about going
with numeric ids any place that humans might run into them.
The death of democracy is not likely to be an assassination from ambush. It
will be a slow extinction from apathy, indifference, and undernourishment.
-Robert Maynard Hutchins, educator (1899-1977)
More information about the developers