[Zope3-dev] Proposed widget/schema work for the Rivah sprint (Thursday and Friday this week)

[Gary Poster]

We'll be doing some work on the widget/schema code at the Rivah  
sprint, Thursday and Friday this week.  This email identifies the  
possible tasks, and proposes the actual choice of work (short answer:  
potentially all but the biggest, and last, 2).  Interested parties  
are invited to comment and suggest, whether or not you plan to be at  
the Rivah sprint.

Some of the ideas below would require proposals before the sprint.   
If I get positive feedback to them on the mailing list, I'd try to  
have small proposals tomorrow so that we could get official consensus  
by time the sprint starts Thursday.  Ones that I think need a  
proposal are marked with *would need proposal*.  I only want to write  
each of these if I believe it's likely I have consensus, so please  
tell me now if you are concerned. :-)

Many of the ideas below have code that Zope Corp already has waiting,  
which need a little bit of TLC to be put in the core.  These are  
marked with *code exists*

Possible topics

1 Flesh out the 'source' design and implementation so it can replace  
and deprecate vocabularies.  Specifically, to match the capabilities  
of vocabularies, we'll add an interface that a source can implement  
if they want to be bound to a context; and we will make it possible  
to have iterable sources (for small collections as would be  
appropriate for selections, radio button groups, checkbox groups,  
etc.).  This will reduce the potential for confusion by letting  
sources be the 'one true way' to describe possible options for a  
choice, instead of the current overlap of vocabularies and sources.   
The primary advantage to sources over vocabularies are that the model  
is cleaner; the only additional feature is the ability to configure  
different tokens for a given source.

2 Clean up the exceptions widget framework.  The use of the widget  
input error is quite messy: see collector issue 273.  The idea would  
be to make the use of the errors argument more consistent and more  
restricted, and make the 'doc' implementation simpler.

3 Make the arbitrary constraints in the schema framework more  
powerful: specifically, allow a field to accept more than one  
constraint, and have the constraints raise errors (with an i18n doc,  
if desired) rather than return an uninformative Boolean.  This can be  
done in a backwards (and deprecation) compatible way by keeping the  
constraint argument and adding a constraints argument wit the new  
semantics; or with another approach. *would need small proposal*  
*code exists*

4 Recognize and document that the 'default' field argument is  
actually 'initial value'.  That is, if you set a field with a default  
to the missing_value, the default does not become the field's value:  
the 'default' value is only used if the value has never been set  
(i.e., during creation or when there is no previous state of the  
value).  Possibly rename to 'initial_value' (with deprecation  
support).  *would need proposal*

5 Allow fields to accept a default (or initial_value, as above) *or*  
a default_getter (or initial_value_getter, as above).  default_getter/ 
initial_value_getter would be a callable passed the field's context.   
It should return the desired initial value.  Use cases include  
initializing to now, today, the current user, etc.  *would need small  
proposal* *code exists*

6 Add union field and widget to schema and form, respectively.  A  
union field allows a user to fill in one of several types of values.   
Use cases include faux combo boxes (i.e., a choice or a text line),  
date/duration choices, etc.  Widget is reasonable and has been used  
by ZC for more than a year.  *would need small proposal* *code exists*

7 add combination field and widget to schema and form, respectively.   
A combination field allows a user to fill in multiple values  
simultaneously, and returns a tuple of the combined values.  Use  
cases overlap somewhat with object field/widget, but this is simpler  
to use for simple use cases.  Use cases include range fields.  *would  
need small proposal* *code exists*

8 Add suggestion and MRU (Most Recently Used) widgets.  These widgets  
provide a drop down of suggested (specifically most recently used for  
the MRU widget) values for a choice field.  They really make using  
choice widgets much nicer in many cases.  *code exists* *proposal  
needed for also adding another of our packages to the core, on which  
this relies*

9 Add standard timezone source and widget.  *code exists* for  
something that should really be a shared community effort.  Relies on  
suggestion widget and MRU widget, above.

10 The big restructuring of schema: divide up schema into interface  
values and usage relationships.  This is too big to explain in this  
email, and probably too big to even adequately begin in two days.   
This is the direction Jim wants to take schema, though, and I'm +1.

11 Brainstorm current state of the widget API and base classes and  
start some significant cleanup of the zope/app/form/browser code.

----

I propose that the people working on this stuff during the sprint  
(I'll be one of probably two) try to do the following: 1, 2, plus, as  
time and interest permits, some of 3-9.  10 is too big.  We might  
talk and make some notes about 11, but won't do any implementation.

People who are concerned about any of 1-9 should be sure to respond  
quickly. :-)  As I said, That's a lot of small proposals to write in  
a short period of time, and I only want to bother with the ones that  
seem reasonably likely to be accepted.

Thanks

Gary