[Zope3-dev] Don't create schemas just for forms

[Jim Fulton]

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:jim at zope.com		Python Powered!
CTO 				(540) 361-1714			http://www.python.org
Zope Corporation	http://www.zope.com		http://www.zope.org