On Sep 14, 2006, at 5:00 AM, adamg wrote:

I'm starting to have lots of schemas around. They are mostly for

view/add/edit forms, based on the entity (content object's) schema.

That means they mostly have the same fields with mostly the same


Adding field to a schema is piece of cake. Subclass the original,

the field, but... field order breaks.

Modifying a field's property by subclassing does not work, changing

some property of the derived schema's field changes the original


Deleting a field does not work.

Renaming a field...

To still be able to use the widget&form framwork I keep adding a

lot of redundant information. E.g. to make a field readonly, I have

copy the schema, change that only one field's property. I hope I

miss the copy next time.

So the big question is: how to solve the above things? Anybody done

that already? Any ideas? Any pointers?

Don't create schemas just for forms. If you use formlib, it's easy to define forms without schemas or bases on schemas with adjustments, such as additional or fewer fields, for the form. formlib was developed in part as a reaction to the same sort of observations you're making.

As far as overriding fields, you should do just that, override. I agree that it would be a good idea to:

- make it easier to override and

- make it harder to accidentilally modify an overridden field.

But, as I said above, if you are manipulating schemas just to drive forms, *don't*.


Jim Fulton                      mailto:[EMAIL PROTECTED]                Python 
CTO                             (540) 361-1714                  
Zope Corporation        http://www.zope.com             http://www.zope.org

Zope3-dev mailing list
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to