On 8/30/06, Rahul Akolkar <[EMAIL PROTECTED]> 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. -Rahul
Craig
