On Thursday 24 August 2006 04:56, Philipp von Weitershausen wrote:
> formlib's use of the 'interface' attribute indeed suggests that people
> would expect a different behaviour. Feeling pretty much indifferent
> about this, I just wonder if there are any potential repercussions. For
> example, changing the behaviour will mean that extending an interface
> will cause all fields (incl. attr and method definitions) to be copied
> in the new interface. Any modifications on the base interface fields
> will not be seen in the subinterface...

Right, I think this is the core of the discussion that requires broad feedback 
and some serious thinking.

> > I do think that not being able to deduce the interface of a field
> > correctly is a serious drawback.
> Yup. In fact, I wonder if Attribute.interface is actually used for
> something valuable. I'm pretty sure formlib's form fields don't really
> need it, they already get the schema passed. Plus, a schema field is
> pretty useless w/o the original schema information anyways (because we
> expect formlib to adapt to the schema), therefore I wouldn't mind always
> having to specify the interface that a schema field comes from.  We
> already can do this anyhoo:
>  form_fields = FieldFromInterface(IFoo)
>  form_fields = FieldFromInterface(IFoo).select('foo')
>  form_fields = FieldFromInterface(IFoo).omit('bar')

This is not quiet true. I use formlib in a way that I autogenerate fields on 
the fly without an existing schema. But I agree, this is the common case. I 
think the fix that I checked in last night for formlib covers all existing 
use cases well. If you pass Field instances (not FormField) to FormFields, 
then you should be aware that Field.interface is used to deduce the 

Stephan Richter
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training
Zope3-dev mailing list
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to