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:[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
