IBugTaskSearchBase has three fields that are List()s of Choice()s:
status, status_upstream, and importance. They all need to be so (*),
because it's describing a search form.
[* They don't strictly need to be List()s; they could probably be
defined as zope.schema.Iterable, but it's much the same. ]
If these kinds of fields are a somewhat rare occurance, perhaps it'll
be easier to just document them by hand.
I could even apply some level of automation to it, by setting the
field description to something like:
>>> "Choose from zero or more of: %s" % ", ".join(
... term.token for term in field.value_type.vocabulary)
But, there is a danger that this will leak through into the web UI
where it would be inappropriate. Is there, say, a tagged value that I
could set that the API machinery sees as a description for a field?
Then I could even write a simple decorator to generate an API-specific
description for those fields.
IBugTaskSearchBase has three fields that are List()s of Choice()s:
status, status_upstream, and importance. They all need to be so (*),
because it's describing a search form.
[* They don't strictly need to be List()s; they could probably be Iterable, but it's much the same. ]
defined as zope.schema.
If these kinds of fields are a somewhat rare occurance, perhaps it'll
be easier to just document them by hand.
I could even apply some level of automation to it, by setting the
field description to something like:
>>> "Choose from zero or more of: %s" % ", ".join( type.vocabulary )
... term.token for term in field.value_
But, there is a danger that this will leak through into the web UI
where it would be inappropriate. Is there, say, a tagged value that I
could set that the API machinery sees as a description for a field?
Then I could even write a simple decorator to generate an API-specific
description for those fields.