More custom field revisions

[Sean McAfee]

Gervase Markham <gerv at mozilla.org> wrote:
>It seems to me that the most natural model for custom fields is this:

>When you create a field, you select a number of products, between 1 and 
>N, to which it applies. If you select 1, it's the same as the current 
>concept of a custom field. If you select N, it's the same as the current 
>concept of a global custom field. If you select any number in between, 
>it's the subset.

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?

>This way, you have one mechanism for managing the fields - in a lot of 
>code, they can all be treated the same rather than via this false 
>dichotomy of global vs. product-specific.

>The key thing is that this doesn't remove any abilities from the 
>proposal - those who want only single-product and global fields can 
>still have them. It also, I strongly suspect, makes the implementation 
>simpler because 1-product and n-product fields have more in common 
>internally.

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.
I think that would be difficult for an administrator to keep straight,
and difficult to cleanly represent in the admin interface.  Better,
I think, to impose some degree of order.

>From another message:

>The other thing is that people often read Bugzilla URLs. As spaces get 
>encoded as %20, using them in field names makes them much harder to read.
>
>query.cgi?Wibble%20Fish=Something&%3FFoo%20Field%41=Something%20Else
>c.f.:
>query.cgi?product=Something&component=Something%20Else

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

>From yet another message:

>To summarise, then, there are a few things I really feel I need to 
>insist on :-):

[snip]

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

This is the kind of thing I have in mind:

------------------------------------------------------------
<p>
  Here are some really important fields:
</p>

[% PROCESS custom_field name = 'important_field_one' %]
[% PROCESS custom_field name = 'important_field_two' %]

<!-- other text -->

<p>
  Here are the run-of-the-mill fields:
</p>

[% PROCESS show_custom_fields
           skip = [ 'bottom_field_one', 'bottom_field_two' ]
   #  important_field_one and important_field_two are implicitly skipped,
   #  since they were already processed via the prior custom_field blocks;
   #  bottom_field_one and bottom_field_two are explicitly skipped,
   #  since we'll display them ourselves later
   #
   #  Maybe there should also be "first", "last", and/or "order"
   #  parameters to modify the administrator-defined default ordering?
%]

<!-- other text -->

<p>
  And here are some fields you probably won't care about very often:
</p>

[% PROCESS custom_field name = 'bottom_field_one' %]
[% PROCESS custom_field name = 'bottom_field_two' %]
------------------------------------------------------------

This example only deals with reordering the fields and interspersing other
text, but the field elements themselves could also be provided by custom
template code, as long as everyone agrees on how to record which fields have
already been displayed.


-- 
Sean McAfee -- etzwane at schwag.org