On Fri, Mar 10, 2006 at 11:23:50AM +0100, Christopher Lenz wrote: > Am 10.03.2006 um 03:57 schrieb Alec Thomas: > >I think it would be advantageous to let plugins implement their own > >ticket field types. Progress-bars, integer-only fields, etc. have all > >been requested numerous times. > > > >I'm proposing to add something like this: > > > > class ITicketFieldTypeProvider(Interface): > > """ Provide custom ticket field types. """ > > def get_ticket_field_types(): > > """ Return list of (name, type) tuples, where type is a > > subclass of trac.ticket.field.Field. """ > > This is in addition to the ITicketFieldProvider interface right? Can > you elaborate why we need both?
The ITicketFieldTypeProvider lets you add extra *types* of fields, such as progress bars, a field type that will only accept numbers, etc. The stock types "select", "text", blah blah are implemented via this interface. The ITicketFieldProvider simply allows plugins to provide "custom fields" programmatically (identically to the ticket-custom section). > Also, how does the field type / field get involved in processing the > POST data? This is handled by the ITicketManipulator.validate_ticket(req, ticket) method, though I think your implication that ITicketFieldTypeProvider perform some basic type enforcement is a good one (eg. make sure that int only fields are actually only integers). > > Sorry if those are stupid questions, still need to catch up with your > workflow work. No problem :). There are currently four interfaces. In addition to the two described in detail above, there is ITicketManipulator which is for validation as well as filtering actions and fields. The final interface is ITicketWorkflow which is purely for controlling which actions are available. The reason for having ITicketManipulator *and* ITicketWorkflow is that ITicketWorkflow is a SingletonExtension for obvious reasons, but there are still features that should be "stackable" as it were. For example, the tracticketmojo [1] test plugin implements two ITicketManipulators: one that implements parent/child ticket relationships and one that implements a dedicated "duplicate of X" action. These two extensions can be stacked to provide both features. So anyway, suggestions more than welcome. [1] http://swapoff.org/files/tracticketmojo.py > Cheers, > Chris > -- > Christopher Lenz > cmlenz at gmx.de > http://www.cmlenz.net/ > > > _______________________________________________ > Trac-dev mailing list > [email protected] > http://lists.edgewall.com/mailman/listinfo/trac-dev > -- Evolution: Taking care of those too stupid to take care of themselves. _______________________________________________ Trac-dev mailing list [email protected] http://lists.edgewall.com/mailman/listinfo/trac-dev
