Custom Fields again
gerv at mozilla.org
Tue Dec 10 18:12:19 UTC 2002
"The current thinking is that we decide what the core types of these
fields are that we need to have available, and provide 3 or 4 of each
hardwired in the bugs table with a UI in the admin interface for
customizing the labels shown to the users or hiding/showing those
fields. This gives you a limited ability for adding custom fields,
while not creating headaches and performance issues with multiple joins
This solution seems to me to get the worst features of custom fields
without getting any of the good ones. We all know that
is why we are considering not having them. Joel argues that having
custom fields leads to people defining fields they don't really need,
field proliferation, and a a general muddle. The above plan doesn't
avoid that - it merely limits admins to 3 confusing email fields, 3
confusing multi-selects and 3 confusing text fields.
In addition, this not-quite-generalisation means our code will be
scattered with references to generic_text_field1, generic_multiselect2
or whatever we decide to call these generic fields when we add them to
the bugs table. These will be carried around whether the user is using
them or not.
An advantage given above is that general custom fields mean performance
issues with multiple joins during queries, and this method avoids that.
But this is thinking from an engineering point of view, not a usability
one. If this is a problem, then big installations can content themselves
with the default fields and do no joins. Or they can use mod_perl to
improve performance in other ways. Or get a better database, that does
lots of joins quicker. Or we could optimise our queries in a smarter way.
Enough of this halfway house! :-) Let's have full custom fields,
implemented in a clean, generic and sensible way, or not at all. :-)
More information about the developers