Version 2 (modified by 17 years ago) ( diff ) | ,
---|
Field Refactoring
This is a development scratch pad to outline a few of the requirements and ideas about how to better handle the ticket fields.
For now, this puts aside the generalization of such fields to other objects/resources than Tickets (see GenericTrac for that, 0.12 material).
Goals
Get an "adapted" rendering of standard and custom fields, in the following situations:
- Display of the field's value in the Ticket Box and other similar places (e.g. query and report results)
- Display of the field's value changes, in the Change History and other similar places (e.g. timeline, notification)
- Display of a field editor in the "Properties" fieldset and other similar places (e.g. bulk editor)
- Display of a field selector in the Query view
Some points to consider:
- the distinction between regular and custom types should become fairly transparent at the web UI level (leave the door open for unification later in GenericTrac) — this is (was, even) already the case
- a rendering flexibility similar to the one of "Browser" properties should be reached (see source:trunk/trac/versioncontrol/web_ui/browser.py and source:trunk/trac/versioncontrol/web_ui/changeset.py)
Proposal
A new API for dealing with fields according to the 4 points detailed above should be introduced.
The old 0.9 - 0.11 API should be preserved, as there's a bunch of scripts all over the Trac world that probably depend on it, so ideally no existing method should be modified (I'm thinking in particular to TicketSystem.get_ticket_fields
).
Instead, a new set of methods and objects should be introduced. In order to avoid any confusion between the old and new ways, I propose to use the term property instead of field. This matches the user-visible Properties label displayed in the ticket UI.
There will be a Property class and a set of basic subclasses that correspond to the main types of fields. A resource (tickets only for now) will define the set of properties that it provides (first in TicketSystem.get_ticket_properties()
, but preferably later in TicketDescriptor.get_properties()
, with TicketDescriptor
a subclass of ResourceDescriptor
, the generic handle for resources).
A Property subclass will have methods and attributes for answering the needs enumerated above.
render(context, name, mode, value)
- similar to therender_property
of thetrac.versioncontrol.browser.IPropertyRenderer
(probably some kind of unification is in order)- multiple other methods checking for the 'visibility' status of the field, 'row' display mode, etc.
Each time with a given 'mode', which would be one of:
'ticket'
,'ticket_preview'
,'query'
- multiple other methods checking for the 'visibility' status of the field, 'row' display mode, etc.
Each time with a given 'mode', which would be one of:
render_change(old_context, new_context, name, mode, old_value, new_value)
- similar to therender_property_diff
of thetrac.versioncontrol.changeset.IPropertyDiffRenderer
render_editor(context, name, mode, value)
. There could also be a validation method supporting validation requests that would be handled by a generic property module.render_selector(context, name, mode, values)
, for e.g. the query module.