Uwe Oestermeier wrote:
> "Garrett Smith" wrote:
> I'd see this being something like a ValueChangedEvent that specified
> the object, schema, field name, old value, and new value. This would
> be a nice way to bolt on validation without modifying the schema.
> Yes, that's exactly what I need for versioning.
> Anyone needing more information in ObjectModified can just create a
> new event type with the additional info. This seems application
> specific to me.
> But there is a major problem: How can you reuse an existing
> infrastructure then? You have to write all editing views or other
> components that modify the content objects anew.
It wouldn't be that hard. You would extend EditView (in
zope/app/form/browser) and insert your own event firing as needed. Then
just specify your new view as the class attribute in ZCML. You can
redefine the standard Zope views for the handful of content types they
provide using overrides.zcml.
> In my view
> ValueChangedEvents are usefull in many applications and for many
> purposes (reindexing catalogs, updating views in standalone
> applications, triggering external processes etc.). Would it be too
> much overhead to have them in the framework from the beginning?
I think ValueChangedEvent would be a good addition to the forms
machinery. But if you need something like that now, I'd recommend using
your own edit view class.
Zope3-dev mailing list