At 12:27 PM 10/18/00 +0100, Johan Carlsson wrote:
>Using the following Rule:
>WHEN eventspec STORE myattributelist USING storemyattributes() SAVING
>How does failure to store an attribute get signaled back to the DataSkin?
It does not. An exception in your rule will simply cause the Zope
transaction to abort.
>Can I raise an exception in a SkinScript if a rule fails due to failure of
No. If the eventspec is not matched, the rule will not fire, so you will
not have any opportunity to raise an exception.
>What I really is after is a way to control the change of states.
>To enter one state (changing some attributes to some state)
>the object needs to be in a precondition state (having some attributes set
to some values).
>The rule should fire when the state attributes are changed,
>check the precondition and if true, change the state (the attributes)
>and if not notify the caller (raise exception).
Rules only fire at transaction or subtransaction commit, so you can only
perform your checks at that time. You can perform whatever operations you
wish, but only at that point. If you need to force rules to be checked,
you must ask Zope to do a subtransaction commit, and then you will be able
to catch errors like this:
get_transaction().commit(1) #subtransaction commit
# do whatever
# we're okay, go ahead
Note, however, that if you find yourself doing this kind of thing a lot,
it's a good sign that your class is missing validation that belongs in the
class. If you need the validation to be parameterized or customizable, you
can always determine certain class attributes using attribute providers,
and thus avoid forcing the existence of complex triggers.
In general, triggers are intended to be used as add-ons for data
manipulation or to extend a class which otherwise would be difficult to
extend. They're not for performing the normal logic of a class.
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -