More custom field revisions
gerv at mozilla.org
Wed Apr 30 21:23:10 UTC 2003
Sean McAfee wrote:
> And when you later create product N+1, and want it to have the same
> "global" fields as the original N products, do you need to remember which
> fields you'd previously added to the first N and add them individually
> to N+1?
It's a reasonable point, but doesn't destroy the model. There's two ways
you could play this:
- Say that you have to allocate custom fields by hand for each new
product, because there's no way Bugzilla can know which one you want
- Have the product selection UI phrased as "Restrict to products:" and
differentiate between the cases where the admin selects all N (which
would restrict the field to just those N unless changed manually) and
where the admin selects none at all (which would mean the field was
auto-added to each new product.) This would require a "global" boolean
in the database; but it would only be looked at when doing admin - the
implementation would still be common.
> What concerns me is the spectre of a set of N products on the one side,
> a set of M custom fields on the other (N and M both being large), and
> some arbitrarily complicated set of has-a relationships between them.
You make it sound complex, but it's not. On every "edit custom field"
screen, you have a "Restrict to products:" multiselect. And that's all
> OK, I can see the utility in this. I would ask, though, that the
> administrator not be required to compose from scratch, for every field,
> a name which isn't relevant to the user interface.
Again, you make it sound complicated. I suppose it depends on whether we
define the display names in the templates (which I think we should, but
I'm open to persuasion) but the UI could be something like this
short name (lower-case alphanumeric and underscore): [ ]
display name: [ ]
> The admin interface
> could, for example, propose a reasonable default by downcasing the
> display name and replacing all nonalphanumerics with underscores, and
> twiddling the result to avoid name collision. The administrator could
> then accept this suggestion, modify it, or nuke it and make up a new one.
Hmm. We could do that. If it were me, I'd like to pick my own, but I can
see the value in Bugzilla making a suggestion.
>>- The separation of content from presentation by moving the definition
>>of how and where the fields are displayed to the templates.
> I think it should be possible to modify the presentation of custom fields in
> this way, but I'd rather provide reasonable default behavior that obviates
> the need to perform template-twiddling for each and every custom field.
Oh, I agree that we should display them without intervention - note that
I said "how and where", not "if" :-) In other words, there should be a
default location, and changing it requires hacking templates, plus a
default UI widget, and changing that requires hacking templates.
So your suggestion of how to do it sounds roughly right. :-)
More information about the developers