Domino: the Concept

I’ve been attempting to build a real world application using Domino, just to see how it works. The example is a FlickBook application, and Domino is proving quite easy to use, and is doing what I originally intended, which was to help me organise and visualise my commands better.

I’m not going to show any demos or code here, but I thought I’d explain the concept. To tell the truth I’m not sure if this is just an interesting experiment, or has any serious value, so I would like your opinion.

Some Definitions

Link: represents an instance of a command which may have some metadata injected into it.

Chain: a list of links, executed top down. A chain can be public (invokable from the main framework) or private (accessible only from inside domino).

ChainSet: a collection of chains that declares a list of states in which the member chains are active.

Link Types

[kml_flashembed movie=”http://www.revisual.co.uk/uploads/2009/jan/domino/domino_key.swf” height=”255″ width=”470″ /]

Synch/AsynchProcessLink:
overrides a method with the signiture:

protected function process ( notification:INotification ): void

Changes something within with pureMVC frame work, and/or the incoming notification. Once completed, the next link in the chain is executed.

EvaluationLink
overrides a method with the signiture:

protected function evaluate( notification:INotification ): Boolean

Tests a condition within the pureMVC framework and/or incoming notification, and returns a Boolean value.
false: the next link in the chain is executed.
true: the execution thread is redirected to the link indicated in its metadata. This can be any link in the current chain, or the first link in a different chain (see also ReturnLink).

GosubLink
overrides a method with the signiture:

protected function prepare( notification:INotification ): void

The execution thread is redirected to the chain indicated in its metadata. The prepare method hook allows the outgoing notification to be changed before redirection (see also ReturnLink and Notification Scope).

ReturnLink
final class:
Returns the thread back to its referring chain.

TerminationLink
final class:
Ends the process and notifies the rest of the pureMVC framework.

Notification Scope
Each Chain maintains its own notification. If the thread is redirected to another chain via an EvaluationLink or a GosubLink, then the original notification is restored if and when it is returned to that chain.

Consider this diagram:
[kml_flashembed movie=”http://www.revisual.co.uk/uploads/2009/jan/domino/domino_diagram.swf” height=”775″ width=”470″ /]
We have three ChainSets, one active in the “init” state, another active in the “exit” state, and the third active in both.
The initiation and exit ChainSets have public chains that are invoked on entry into their declared states. The “utils” set’s chains are all private, thus can be accessed only by referral from another active chain.

1) The Init State is entered, and the chain EnterInitState is invoked:

  • CreateActorList (a GosubLink) is executed. This retrieves an Array of class paths from the ConfigurationProxy, adds it to its notification and redirects the thread to the createActor chain (see 2).
  • when the thread returns to the chain, the TerminationLink is executed which ends the process, and sends a TERMINATION notification to the rest of the framework
  • 2) The createActor chain recieves an Array as the notification body:

  • its first link ShiftArray (a GosubLink), shifts an element off the Array, and redirects it (see 3)
  • the second element ArrayLenZero (an EvaluateLink) checks the length of the Array, if it is > 0 it loops back to ShiftArray, otherwise it continues to
  • the final ReturnLink, which returns the thread back to its referring chain
  • 3) the createNotifier chain receives a class path (String) as its notification body

  • the CreateNotifier link (a SynchProcessLink) creates a class instance from the class path, and adds it to the notification body
  • then the RegisterNotifier link (a SynchProcessLink) checks the notification body type, and registers it with the facade accordingly
  • the final ReturnLink returns the thread back to its referring chain
  • The overall effect is to create and register all the application’s Mediators and Proxies from a list in the config when the application enters its init state.

    I think thats all fairly simple to understand… I’ve thought very much along the lines of Chain of Responsibility. If an element does not know how to deal with something, it passes it on. I also have an error handling system prepared and implemented, but not yet tested.

    Should I proceed, the next step is to take the XML and create a tool that visualises it (like the diagrams above which were, alas, laid out by hand).

    I’d love to know what people think:
    An interesting experiment or something with real-world value.

    cheers.

    the xml this visualises is here

    4 thoughts on “Domino: the Concept

    1. I think it’s an interesting idea. As I was reading this I was imagining using it to write a Logo interpreter (i.e. The old skool ‘turtle graphics’ language). These chains, could they call each other recursively?

      -=Cliff>

    2. cool :)

      I haven’t done anything on this for a while, as I’ve been in several other projects.

      yer, I think they can be called recursively. what were you thinking?

    3. no they can’t be called recursively
      by which I mean that a command cannot call themselves (interesting concept which I will think about),
      they can however change their data, loop back, and repeat the process on a new chuck of data. which can be made to do the same thing… and I feel is some what safer…

      also I would say that full recursion on this level should not be needed, your data objects should be intelligent enough to do it themselves.

    4. Pingback: Domino rides again «

    Leave a Reply

    Your email address will not be published. Required fields are marked *