More custom field revisions

[Christopher Hicks]

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 
ignoring it.

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.

-- 
</chris>

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)