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

Jim Fulton jim at zope.com
Tue Aug 30 09:22:20 EDT 2005


Garrett Smith wrote:
>>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.
> 
> 
> Funnily, I just faced this dilema earlier today. I nearly created an interface like this:
> 
>   class IInitialValue(Interface):
>       """An interface for obtaining an initial value for an object."""
> 
>       def get():
>           """Returns the initial value."""
> 
> IMO, this is superior to field.initial. E.g.
> 
>   zapi.getMultiAdapter((field, context), IInitialValue).get()
> 
> Perhaps this pattern could be used for getting an ISource from a field. E.g.
> 
>   zapi.getMultiAdapter((field, context), ISource)

I think that sources are different than initial value.  I really don't
see any role that "initial value" has in an object specification.

A schema is a specification for an object that provides the schema.
An initial value doesn't constrain or specify the object.  If anything,
it constrains applications that create the object, but in a rather unclear
way.

Sources, OTOH, are about the specification of a value. A source defines the
set from which a choice is made.

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