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:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714 http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
_______________________________________________
Zope3-dev mailing list
[email protected]
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
