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
_______________________________________________
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to