At 12:27 PM 10/18/00 +0100, Johan Carlsson wrote:
Using the following Rule:
WHEN eventspec STORE myattributelist USING storemyattributes() SAVING
momentolist
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 the "WHEN eventspec"?
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: try: get_transaction().commit(1) #subtransaction commit except MyException: # do whatever else: # 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.