New custom fields proposal

[Sean McAfee]

Gervase Markham <gerv at mozilla.org> wrote:
>Sean McAfee wrote:
>> Each string field is flagged as belonging to one of two varieties:
>> short and long.  A short string field can hold a maximum of 255
>> characters, and may contain no vertical whitespace characters
>> (carriage return, newline, or vertical tab).  It is represented on
>> Bugzilla's Web interface using a single-line text form element.  A
>> long string field can hold large amounts of text, possibly consisting
>> of several lines.  It is represented on Bugzilla's Web interface as a
>> multiline textarea form element.

>Is there a max size for the long field? I think 32K should be OK.

I was thinking long strings would be stored as mediumtexts, but yeah,
a 32K text is probably plenty.

>> [Open question: Should there be a limit on the size of the set of
>> valid strings?  If so, should this limit be global or per-component?]

>Why would one need a limit?

I was thinking in terms of sanity checking, but that's probably more the
domain of the admins.

>> [Open question:  Should the field subtypes described above really be
>> their own top-level types?]

>Makes sense to me. Multi-select and single-select.

I meant it more as a question of terminology.  Assuming float fields are
eliminated (as everyone seems to prefer), should one say "There are four
field types: integer, string, date, and selection" or "There are five field
types: integer, string, date, single-selection, and multi-selection"?

>> Presentation
>> ============
>
>Moving to a CSS-based layout should make it much easier to add and 
>remove fields.

How so?

>Also, while the default templates should contain generic code for 
>displaying any custom fields, it should also be possible for admins to 
>hard-code the position of the field themselves, and flag in the template 
>that they've done so so that the template doesn't print it again.

Makes sense.


--Sean