Ticket #127 (assigned enhancement)

Opened 16 years ago

Last modified 9 years ago

Vocabularies must be associated to fields not widgets

Reported by: fguillaume Owned by: gracinet
Priority: P2 Milestone: CPS 3.5.7
Component: CPSSchemas Version: unspecified
Severity: normal Keywords: vocabularies
Cc:

Description (last modified by gracinet) (diff)

Vocabularies must be associated to fields not widgets

For a select widget (simple or multiple), there is an associated vocabulary. At the moment it's associated to the widget, but it really should be associated to the underlying field. Also the default for this field could be gotten from the vocabulary (should the vocabulary have a default itself?).

This kind of field may also want to allow a "None" value (but YAGNI?).

Change History

comment:1 Changed 16 years ago by fguillaume

  • Status changed from new to assigned
  • Component changed from CPSDocument to CPSSchemas

Changing product to CPSSchemas.

comment:2 Changed 16 years ago by fguillaume

  • Keywords vocabularies, hc@nuxeo.com added

comment:3 Changed 16 years ago by disabled-hc@…

Are you sure about that ? Vocabularies are to be know by the widgets, to render the select box. Fields just have to store a value, the key is our case.

comment:4 Changed 16 years ago by fguillaume

Vocabularies will be used by widgets, yes, but they have a fundamental role at the field level to be able to enforce allowed values.

comment:5 Changed 16 years ago by bdelbosc

  • Priority changed from P2 to P3
  • Severity changed from normal to enhancement

comment:6 Changed 9 years ago by gracinet

  • Owner changed from fguillaume to gracinet
  • Priority changed from P3 to P2
  • Description modified (diff)
  • Milestone changed from unspecified to CPS 3.5.3

Also there are use cases where there is no widgets-related renderings, but using the value instead of the key is needed.

Two such cases are CSV exports for non technical users (a title would be nice, too) : can't give them an obscure key from some corporate information system, and full text indexing. Both need i18n awareness, btw.

I would prefer doing this by adding a property on the String Field than creating a new field type, as this is obviously simpler for BBB. Actually, one could still let the widget override the vocabulary, and hence not need to upgrade anything.

Finally, we'd need a new, clean, method on DataModel to do the introspection from the field. The most pythonic way would be to declare the _fields attribute part of the API (and maybe rename it, keeping a property for BBB again).

If I didn't forget anything, this is fairly simple.

Note: See TracTickets for help on using tickets.