using DCI together with State machine to model Controllers

[Hai Quang Kim]

Hi group,

 

I was recently working on UI Tool and framework. I am reading http://www.amazon.com/Constructing-User-Interface-Statecharts-Horrocks/dp/0201342782 to build UI tool like 

http://www.wpftutorial.net/SketchFlow.html.

When I think about UI framework (some thing like http://www.svgopen.org/2004/papers/SPARK/)

I have the same thinking with the author in this paper:

"The framework uses the MVC pattern in two distinct ways: for widgets and for applications. 

Each widget defines its own Model, its own Controller and its own View. 

The application itself has its own View (the UI components), its own Controller (the logic that interacts with the components) and its own Model (state information and business logic)."

So if each widget is an MVC then it is a chance to use DCI for the widget code as well.

The main idea here is: To model the Controller as a state machine and using a decision table with Event and State as an Input, DCI Context as an output for each (event, state).

This table can be changed as run-time so that we can reuse, replace the behavior of the Object as will.

Eg:

| Event                         | State                   |    Context   |

| PlayButtonPressed    | Disc loaded        |    PlayCD   |

| StopButtonPressed    | Playing               |    StopCD  |

Below is my thinking. 

It is still in the early stage and very simple. 

Trygve encourages me to share this with the group to get more review and feedback.

1) The current state of UI framework

As you know, UI framework is complicated with event pump, buttons, panel classes.

I worked on them before. My Button code was thousand lines (and still inherit from Flash MovieClip)

It was a night mare to debug, read code in UI framework. 

--> Is the Button code handling too many use cases at the same time?

2) The UI Behavior in WPF (DCI alike)

In WPF, they have concept of reuse behavior which is working like DCI.

In WPF UI behavior, they have object like Roles, and register event from those Roles and when UI event get triggered they trigger the interaction between Roles to do UI work like drag and drop...

This behavior can be injected to any suitable UI Control for reuse. So people actually need and do DCI some forms different somewhere.

(eg http://www.wpftutorial.net/Behaviors.html)

3) The State Chart book

http://www.amazon.com/Constructing-User-Interface-Statecharts-Horrocks/dp/0201342782

Mr Horrock has the idea to use State Chart to model the Controller in the MVC.

The state chart is visual of state machine with Concurrent States, Nested State, State with history....

4) The DCI: Capture the System Operation at Use case level, the missing piece for Readable Code

5) My humble View of  how everything should work together

- When I think about all the above ideas, it turns out that a UI Control like Button itself is a MVC: Button Data, ButtonController, Button View.

- So I am think why we cannot use all of these idea together to make code more readable at all levels.

(Trygve already did try this in Prokon.)

And it may open a chance to make visual programming that really works.

- The DCI Baby Editor is the missing piece of the entire Visual programming field. People are using flow chart for it which is more like procedural programming.

 

Attached is my sketch for the idea.

- On the left we have Render thread that can look at Data and render the UI Control: Mouse, Button, Panel

- The Data layer have Native Data, Data Context and data binding to avoid manually pull and push data from View to Model.

- The Data should be dump like DCI Data

- If the Data is changed it will send Changed Event to Event Bus ( there a lot of things to discuss how to implement the event bus in UI, domain, application...)

- The Controller is the most interesting part of this View:

+ In DCI we still just say Controller will start the Context (construct objects, context, run....) but no more than that.

+ Here I model Controller as a state machine for more control and better to handle different states of the View

+ We have decision table with take an Event, State as Input and out put a DCI Context, then trigger the Context ( This table can be reused and extended as will, this can be a GREAT deal of code reuse and extensibility like Open Close Principle )

+ The Context then will run interaction of Roles to change Data

+ Data will then trigger next cycle of interaction....

- So the loop start with:

 

    (0) Hardware Event  (Event Bus)

-> (1) Decision Table (event, state, context)   ( in Controllers)

-> (2) DCI Context -> (3) Change Data   (Decision Table)

-> (4) Changed Event  ( In Data, to Event Bus)

-> (0) for higher level of objects.   (Event Bus)

If anyone has experience with UI framework please help to give some feedback and share your view.

thanks a lot.

/quang