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

properties.

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

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

too.

Deleting a field does not work.

Renaming a field...



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

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

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

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

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

Reply via email to