shale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig McClanahan" <>
Subject Re: [dialog2] "Advance" failures and names
Date Wed, 30 Aug 2006 22:59:59 GMT
On 8/30/06, Rahul Akolkar <> wrote:
> Some notes from looking at the dialog2 sandbox modules:
> a) Dealing with failures in:
> Context#advance(FacesContext, String)
> It is possible that advancing a dialog might fail (say there is no
> such state defined as indicated by a transition target), and while
> many of these errors can be caught by static analysis and model
> checking tooling (indeed, Commons SCXML, for example will warn of many
> such errors at parsing time), how should the engine that gets plugged
> in report such an error, if one at all occurs? Doesn't make much sense
> to have a typed exception here since its going to bubble up to the
> handleNavigation() method without a throws clause.

Some sort of logging would probably be appropriate.  We could also define an
event (in the JavaBeans sense, where you can register listeners) on the
context class, so the app can choose to be notified when an exception
occurs, and take whatever action *it* wants to take.

NIT-PICKS (yes, I'm aware I'm nit-picking below ;-):
> b) In line with FacesContext, InitialContext, PageContext etc., should
> we rename the Context interface to DialogContext? Context seems way
> too generic and would make the variable declarations more readable,
> IMO. Also appropriate for me to point out that there is a Context
> interface in Commons SCXML but there was lot of time spent mulling
> over that name FWIW now.

I think you're right ... it's hard to remember what kind of context you're
talking about otherwise.  I'll make this change when I import your
shale-dialog2-scxml stuff tonight.  (Gotta love refactoring engines in IDEs

How about Contexts though?  DisplayContexts would be an obvious choice, but
the actual functionality of the class is a little more than just a cache of
the active things.  Maybe DialogContextManager?

c) Based on my own preference of code readability, I've left SCXML in
> upper case in classnames in Commons SCXML (so, SCXMLExecutor,
> SCXMLDigester etc.). If anyone cares about the "synergy" in naming
> between the Shale module and the library, perhaps someone can rename
> ScxmlContext and ScxmlContexts to match that style?

When integrating a third party library, it seems perfectly reasonable for us
to adopt that library's spelling of its own names :-).  So, SCXML it is.



  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message