On 8/30/06, Craig McClanahan <[EMAIL PROTECTED]> wrote:
On 8/28/06, Rahul Akolkar <[EMAIL PROTECTED]> wrote:
>
>
> Correct, that schema is immutable as far as we're concerned. And for
> obvious reasons, since we can't really model an on-exception
> transition attribute in a UML state chart (its too Java specific) or
> in classical state chart theory either. But what it can be treated as,
> is simply an event whose name is the FQN of the exception (this is
> what we've been promoting as the best practice, especially in the
> realm of SCXML custom actions, where such executable content may throw
> "derived events").


Is an FQN unambiguous compared to other possible event names?
<snip/>

Yes, if done right. The best practice in event names is that, like
package names, they imply a particular ontology, starting from the
broadest to the narrowest using "." as a separator. This is one of the
reasons I chose the "faces.outcome" event name. In the end, the event
names are decided by the user. As long as the user has a naming scheme
that is followed in the SCXML documents used for that usecase, we're
fine.

Another interesting usage of such a event naming scheme (which is
probably not immediately obvious) is that it also works like a
wildcard scheme (though this bit doesn't always translate well to the
Java exception FQNs) i.e. if the following is a candidate transition:

<transition event="error.send" ... />

when an event "error.send.targetunavailable" is triggered, the above
transition will be followed (since error.send.targetunavailable is
considered to be a "type of" error.send due to the implication of an
ontology).


 I suppose it
could be if you disallowed "." in any other kind of name.  A couple of other
thoughts on how one might express this:

* An "exception:FQN" syntax that uses a prefix in the same spirit as
  entering a dialog through a logical outcome that has a special prefix.

* Since the guard condition can be an expression, some concise way
  to evaluate an expression to see if an exception was thrown.

<snap/>

Sure, these are other options.

-Rahul


Craig


Reply via email to