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

Jim Fulton jim at zope.com
Mon Aug 29 16:50:58 EDT 2005


Gary Poster wrote:
...
> 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*

I'm uncomfortable with this. Right now, I think fields do too much.
They have too much application logic.  This would add more.  The whole
concept of "initial value" seems to be very application dependent.
Maybe it would be best to just drop the default field altogether
and introduce adapters for computing initial values in those special
cases when we need them.

...

> 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*

I have an open mind, but I'm a bit skeptical (as you know :).  I expect
this proposal to be a bit controversal.  Perhaps we can plan to go another
round of brainstorming during the sprint.

> 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.

See:
http://mail.zope.org/pipermail/interface-dev/2004-June/000048.html

Jim

-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org


More information about the Zope3-dev mailing list