[Zope3-dev] Re: Alternate schema types

[Gary Poster]

On Jul 12, 2005, at 11:50 AM, Tres Seaver wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Gary Poster wrote:
>
>
>> On Jul 12, 2005, at 11:01 AM, Tres Seaver wrote:
>>
>>
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> I would like to break the hard-wired assumption in the forms /  
>>> widgets
>>> machinery that all schemas must be interfaces with fields;  in
>>> particular, I would like to make the introspection of the  
>>> fieldset  from
>>> a given schema pluggable.
>>>
>>
>> The use cases make sense to me.
>>
>> An observation is that the proposed implementation only works with
>> zope.app.form and perpetuates some other assumptions within the
>> zope.app.form.utility module--assumptions that we have found   
>> constraining.
>>
>> The zope.formlib package (http://svn.zope.org/zope.formlib/trunk/,
>> formerly known as zc.page) already provides a more powerful   
>> abstraction
>> in IFormFields.  The abstraction is only helpful with the   
>> zope.formlib
>> utilities, though (not zope.app.form.utlilty).
>>
>
> Would a similar indirection work there?  E.g., instead of:
>
>
>>>> from zope import interface, schema
>>>> class IOrder(interface.Interface):
>>>>
>     ...     identifier = schema.Int(title=u"Identifier",  
> readonly=True)
>     ...     name = schema.TextLine(title=u"Name")
>     ...     min_size = schema.Float(title=u"Minimum size")
>     ...     max_size = schema.Float(title=u"Maximum size")
>     ...     now = schema.Datetime(title=u"Now", readonly=True)
>
>
>>>> from zope.formlib import form
>>>> class MyForm:
>>>>
>     ...     form_fields = form.Fields(IOrder)
>
> we could do:
>
>
>>>> from zope import interface, schema
>>>> class IOrder(interface.Interface):
>>>>
>     ...     identifier = schema.Int(title=u"Identifier",  
> readonly=True)
>     ...     name = schema.TextLine(title=u"Name")
>     ...     min_size = schema.Float(title=u"Minimum size")
>     ...     max_size = schema.Float(title=u"Maximum size")
>     ...     now = schema.Datetime(title=u"Now", readonly=True)
>
>
>>>> from zope.formlib import IFormFields
>>>> class MyForm:
>>>>
>     ...     form_fields = IFormFields(IOrder)
>
> and register zope.formlib.form.Fields as the "default" adapter factory
> for IFormFields? (where IFormFields would be the 'IFormIntrospector'
> I sketched)?

I don't think that's necessary for the interface-based forms, or even  
for file-system defined forms generally.  For interface forms, the  
API that zope.formlib's fields implementation provides is very  
convenient and allows a number of very useful things that your  
example does not.

The IFormFields has power simply as a contract, without involving  
adaptation: the zope.formlib utilities should allow filesystem or  
persistent implementations, using a variety of sources, without
caring.

That isn't to say adaptation isn't useful anywhere here: I'd expect  
adaptation to be more interesting with dynamic or persistent schemas-- 
for instance, a constructor that allows you to provide a source of  
any type (RDB table object or a XML Schema File object or...), and  
adapts the object to get an IFormFields to slam on an instance,  
either to be used with the helper classes in zope.formlib.form or the  
lower-level utilities there.

>> A notable downside is that it is not an out-of-the-box fit for Zope
>> 2.8/Five, since the package relies on Python 2.4.  A Python 2.3   
>> version
>> probably would be easy enough, removing some of the Python  2.4  
>> features.
>>
>
> Those are mostly decorator-based, right?  In that case, aren't they
> basically sugar?

Yup.  Might be some generator comprehensions.  Easy enough to come up  
with a 2.3-happy version, I'd guess, as I said.

Gary