Screenplay Analogy

[Tom B.]

Hi,

During the last 3 days I've been reading up about DCI. I think I'm starting to grasp the concept piece by piece but still there are some parts which I'm not quite convinced about. To illustrate the concept I've been visualizing DCI as a screenplay. Now I'm only left wondering, since it has been brought up a couple of times before and it isn't really picked up as a correct analogy. Which part of the screenplay doesn't match up?

The way I currently see it is the following:

We have a screenplay containing several scenes.
- Screenplay being the system here and scenes being the different "use cases"/ contexts. Use cases and context aren't interchangeable right?

We have several actors in a screenplay all carrying out their individual roles. Yet an actor isn't bound to 1 role. i.e. the butler can also play the killer.
- Actor is a dumb object who only knows his attributes i.e. gender or name (Not sure if the object has any methods except for the methods it gets assigned by the role.)
Since there's currently no such thing as Roles inside most OO langs most examples inject the methods from the role into the Object. In an ideal situation we just define the role and it methods and not really inject it but rather use
it as some sort of "mask" so that most Actors should they fit the requirements can play the role of the Character. I.e. if we have a mask for the character Romeo it doesn't really matter who's doing the playing. Cause they always look like Romeo.

During each scene the actors are interacting with each other inside of the provided scene.
- The scene gets triggered by something like:
KissingSceneCtx  ks = new KissingSceneCtx(RoleRomeo, RoleJullia);
ks.play();

Well typing this out directly makes me think a couple of things:
- I'm not entirely sure but can a System be part of another context? 3 Screenplays end up being some sort of sequel to each other and thus resulting in a new context
- Why do we assign the Roles in a Context and not inside of the System. Isn't it weird to see the first scene play a girl the role of Julia and the next scene Julia ends up being played by some bad-ass hairy guy? If so should the RoleMethods stay inside the object instead of some sort of dejection at the end of a scene?

The following question actually came from looking at the php example framework and some of the posts here from Risto. He uses something he calls DCI-V isn't that the way DCI / MVC + DCI should actually work? I mean where should I otherwise leave any form of GUI ? Putting it in a role doesn't seem to fit neither does placing it in a separate context (at least not the way I currently look at contexts).

Also I made a small JavaScript example of how I currently see it: (don't mind the dialogue or the fact that I didn't remove the roles/listed the roles so one doesn't have the "schizo" problem)
http://www.neo-effectz.com/jssnippets/DCI/

But is this a bit the concept of what one would expect of DCI or am I heading into a dead alley?

Thanks in advance,
 Tom

[rune funch]

Den 07/03/2012 kl. 20.38 skrev "Tom B." <t.b...@gmail.com>:

> Well typing this out directly makes me think a couple of things:
> - I'm not entirely sure but can a System be part of another context? 3 Screenplays end up being some sort of sequel to each other and thus resulting in a new context

A context can play a role in another context. P

> - Why do we assign the Roles in a Context and not inside of the System. Isn't it weird to see the first scene play a girl the role of Julia and the next scene Julia ends up being played by some bad-ass hairy guy?

Happens all the time in movies, there's stunt doubles and booty
doubles and there's artistic freedom where the director experiments
with multiple actors for the same role and all other sorts of reasons.
As long as it a conscious decision it's not a matter or whether it's
weird or not but whether it yields the desired result

> If so should the RoleMethods stay inside the object instead of some sort of dejection at the end of a scene?

The RoleMethods belongs to the context the object looses those
abilities when ir's no longer playing that role

[rune funch]

Den 07/03/2012 kl. 20.38 skrev "Tom B." <t.b...@gmail.com>:

> In an ideal situation we just define the role and it methods and not really inject it but rather use
> it as some sort of "mask" so that most Actors should they fit the requirements can play the role of the Character. I.e. if we have a mask for the character Romeo it doesn't really matter who's doing the playing. Cause they always look like Romeo.

This is exactly what Marvin aims at (http://fullOO.info/Examples/Marvin)

[Tom B.]

That makes Marvin probably the best place to start. I've looked at it briefly and it really helps to understand. Maybe it would help if there's like a step by step tutorial in several languages a bit like the NeHe tutorials but than explaining everything first from Marvin perspective than from other languages.

But what I was really wondering was am I on the road to DCI or am I missing something? Also I would really like to know how a GUI should be implemented in case one chooses only to use DCI or is DCI complementary to MVC?


On Wednesday, March 7, 2012 8:50:06 PM UTC+1, Rune wrote:

On Wednesday, March 7, 2012 8:50:06 PM UTC+1, Rune wrote:

On Wednesday, March 7, 2012 8:50:06 PM UTC+1, Rune wrote:

[rune funch]

Den 07/03/2012 kl. 22.34 skrev "Tom B." <t.b...@gmail.com>:

> But what I was really wondering was am I on the road to DCI or am I missing something? Also I would really like to know how a GUI should be implemented in case one chooses only to use DCI or is DCI complementary to MVC?

I'd say it sounds like you're off to a pretty good start. There are
different ways to combine MVC and DCI and quite a few posts on the
subject here on the list amongst them a good few by Trygve and Jim
they would be worth searching for. In general they are orthogonal
concepts. Where one system operation and therefor context might
include the use of several controllers and views triggering different
steps of the use case.

If you haven't already read it I strongly suggest reading the lean
architecture book

-Rune

[Tom B.]

Ok good to hear. I'm currently ploughing trough the book but since I'm not a big reader, progress is slow. Besides that the question of how to combine the two occupies my mind and in order to truly read and understand I need to find the answer ( I know from experience I'll only read with the question in mind thus tossing other info aside if it doesn't match ). 

So I've been searching this group for the examples you mentioned and I only managed to find a Squeack example from Trygve. Could you maybe link me to the place where I can find another? I would really appreciate it.

 Tom

Op donderdag 8 maart 2012 07:38:27 UTC+1 schreef Rune het volgende:

[rune funch]

You Can find more examples at http://fullOO.info/Examples/

-Rune

--
You received this message because you are subscribed to the Google Groups "object-composition" group.
To view this discussion on the web visit https://groups.google.com/d/msg/object-composition/-/JN7NGRu2O2gJ.
To post to this group, send email to object-co...@googlegroups.com.
To unsubscribe from this group, send email to object-composit...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/object-composition?hl=en.

[Tom B.]

Ok thanks but those are more general DCI examples I was more looking for DCI combined with MVC but still thanks though or am I thinking about it to complex?
The current way I'm considering to combining both:

View represents the default GUI.
 \/
Controller takes input from GUI and controls/creates Views. The controller also invokes the different contexts.
 \/
Contexts handle the roles and interactions
 \/
Models encapsulate the data objects.

About the frontloader Marvin example
 Shouldn't the print action actually be in a separate context with multiple entry points?



Op zaterdag 10 maart 2012 15:53:04 UTC+1 schreef Rune het volgende:

To post to this group, send email to object-composition@googlegroups.com.
To unsubscribe from this group, send email to object-composition+unsub...@googlegroups.com.

[Trygve Reenskaug]

Hi Tom,
There are many variants of MVC. The following is its simplest form that reflects the essence of MVC:

• Model. The Model consists of objects that represent domain information.
• View. The View is a transformation between invisible Model data and a presentation that lets the human user grasp its meaning. The View also accepts input from the user and updates the Model accordingly. (In some versions, there is a further separation of concern by splitting the View into two objects; one for output and one for input.)
  
• Controller. The Controller is responsible for setting up and coordinating one or more Views. (E.g., by making a selection in one View visible in all Views where this is appropriate).

DCI is appropriate whenever two or more objects interact to achieve some purpose. An obvious candidate is the update of the display in response to a changed Model. This is done by a Context and its algorithm transforms invisible Model data to pixels on the display. A Model object will clearly play one of the Roles. A View is another. The display algorithm is coded as Role methods. Variables in the Context object are used to hold data that belong to the algorithm as a whole. They are exposed to the Role Methods as (auxiliary) Roles.
 
My Squeak/Planning example illustrates this point. . The test output for this example is attached. There are three use cases: Display the top View (the dependency diagram). Frontloading: Calculate earliest start for all activities. And finally Display the bottom View (the Gantt diagram). There is one Context for each of them. The Squeak code is here:
    http://fulloo.info/Examples/SqueakExamples/BB4bPlan/BB4bPlan.html
    (All class names in this example are prefixed with BB4b)

I have programmed many versions of this example through the years. In all earlier versions, Model code was very  confused with a mixture of methods belonging to the different use cases. The same applied to the View code, but not to the same extent. With DCI, code for the different use cases is clearly separated. It is also easy and safe to change any of these algorithms. And for the first time, more use cases can be added without the code getting more confused. Examples are backloading, resource allocation, and progress reporting.

In conclusion: Whenever we need to code the interaction between two or more objects, the DCI separation of concern clarifies the code.

Cheers
--Trygve

To view this discussion on the web visit https://groups.google.com/d/msg/object-composition/-/X-Aj1W_LjNMJ.
To post to this group, send email to object-co...@googlegroups.com.
To unsubscribe from this group, send email to object-composit...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/object-composition?hl=en.

--

Trygve Reenskaug       mailto: try...@ifi.uio.no

Morgedalsvn. 5A         http://folk.uio.no/trygver/

N-0378 Oslo               Tel: (+47) 22 49 57 27

Norway

[Tom B.]

Hi Trygve,

Thank you for your response. It did change my perspective on MVC quite some. I only know MVC from web programmers point of view. In web programming (if I'm off please correct me) the view isn't the initial from which the user interacts with the system. Rather the user calls a method on a controller which in its turn communicates with the model and tosses the model to the view.

If I understand what your saying correctly (I'm having a bit trouble understanding Squeak so I can't really verify from your example code)
DCI + MVC should look a bit like this:

- Data & Model are much a like if not entirely alike. Both represent domain information
- Context represents "Use case" and contains the interactions
- Controller creates and coordinates Views (i.e. providing a view with the correct model/data for display)
- View or GUI translates model/data to something with meaning for the user. The view also captures events and methods invoked by users (i.e. "press button")

If my understanding is correctly why is there still a place for controller to be used here? Isn't "Translate model to meaningful data" an "use" of the system thus putting it in a context? If it is it would cause the controller to be nothing more than a sort of factory producing views. That may be fine but some how it doesn't feel like the proper use for a controller. Again I'm not 100% confident about this so please correct me if needed

Thanks,
 Tom


Op zondag 11 maart 2012 13:18:52 UTC+1 schreef trygve het volgende:

--

Trygve Reenskaug       mailto: try...@ifi.uio.no

[Mikey B]

Hi Tom,

I shell try and explain from my limited understanding,

On 14 March 2012 21:53, Tom B. <t.b...@gmail.com> wrote:

Hi Trygve,

Thank you for your response. It did change my perspective on MVC quite some. I only know MVC from web programmers point of view. In web programming (if I'm off please correct me) the view isn't the initial from which the user interacts with the system. Rather the user calls a method on a controller which in its turn communicates with the model and tosses the model to the view.

DCI is concerned with Object-Oriented programming (data abstraction, messaging, encapsulation etc).

I believe a View is a special type of role, It requires the inner data of the [model] object (setters/getters), rather than asking the object to perform something on itself.

What you receive in your web browser is the inner data of an object. Whats left for you is;

* Recreate the model object, with setters/getters (rest) or with messages (soap)

* Create the representation objects (buttons, forms etc)

* Give them their roles (render/update), so changes are dealt with.

 

If I understand what your saying correctly (I'm having a bit trouble understanding Squeak so I can't really verify from your example code)
DCI + MVC should look a bit like this:

- Data & Model are much a like if not entirely alike. Both represent domain information
- Context represents "Use case" and contains the interactions

Context - The circumstances that form the setting for an event, statement, or idea ...

A context holds one or more use-cases. A small cue-card starts a use-case. The use-case steps are distributed among roles within the context to achieve the goal.

 

- Controller creates and coordinates Views (i.e. providing a view with the correct model/data for display)
- View or GUI translates model/data to something with meaning for the user. The view also captures events and methods invoked by users (i.e. "press button")

If my understanding is correctly why is there still a place for controller to be used here? Isn't "Translate model to meaningful data" an "use" of the system thus putting it in a context? If it is it would cause the controller to be nothing more than a sort of factory producing views. That may be fine but some how it doesn't feel like the proper use for a controller. Again I'm not 100% confident about this so please correct me if needed

Im not sure myself on this, Controller as a "Role" may mean from the general sense of responsibility, and not a DCI role. Or it maybe from the fact that MVC has many flavours, with which Controller does a lot more (pygtkmvc, ruby, and cocoas take on MVC).

From what I can tell the Controller is the "cue cards" that initiate a use-case (builds the view objects, possibility links triggers to other use-cases, and links each player to their roles).

Mike Brown

 

To view this discussion on the web visit https://groups.google.com/d/msg/object-composition/-/jTbhDZD6XmcJ.

To post to this group, send email to object-co...@googlegroups.com.
To unsubscribe from this group, send email to object-composit...@googlegroups.com.

[Mikey B]

p.s.

depending on website complexity, you can omit rebuilding the model. the view Role POSTs directly to the remote object.

[Tom B.]

Hi Mike,

Thank you. I'm assuming your base of reference is a "Web 2.0 Ajax based web application" or an "Web API" ? The use of the view I'm most familiar with is... giving the view a model and let the view handle how to deal with it. Recreating the model or giving roles are in my opinion things that and are better fit for the front-end (Javascript), but since js only adds "fanciness" or dynamics to a page it. I rather see it as a different system. From how I see it the view really only translates the model to something useful for the user ( i.g. a graph is hard to understand if you only see the raw data. If you put it in a nice chart though almost anyone can quickly see what the results of the data is). For me that's the sole purpose of a view (Although it can use Javascript to enhance the image). So maybe I'm a bit off at saying its a different system.

"Context - The circumstances that form the setting for an event, statement, or idea ..."

I find this a bit vague actually. I would prefer to state it:
"Context - Is an environment in which the Interaction takes place"
but that's just my 2 cents.

I could see the cue cards being the controller, but if it's functioning like a trigger of contexts or like a "view factory". It really isn't a controller the way Trygve meant it?

*I just noticed your p.s. directly posting to remote object what do you mean by that? Directly posting into a query or posting to a validator context and than pushing it in the db.

Thanks,


Op donderdag 15 maart 2012 12:56:42 UTC+1 schreef Mikey het volgende:

Hi Tom,

To unsubscribe from this group, send email to object-composition+unsubscribe@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/object-composition?hl=en.

--
You received this message because you are subscribed to the Google Groups "object-composition" group.
To view this discussion on the web visit https://groups.google.com/d/msg/object-composition/-/X-Aj1W_LjNMJ.
To post to this group, send email to object-composition@googlegroups.com.

To unsubscribe from this group, send email to object-composition+unsubscribe@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/object-composition?hl=en.

--

Trygve Reenskaug       mailto: try...@ifi.uio.no

Morgedalsvn. 5A         http://folk.uio.no/trygver/

N-0378 Oslo               Tel: (+47) 22 49 57 27

Norway

--
You received this message because you are subscribed to the Google Groups "object-composition" group.

To view this discussion on the web visit https://groups.google.com/d/msg/object-composition/-/jTbhDZD6XmcJ.

To post to this group, send email to object-composition@googlegroups.com.
To unsubscribe from this group, send email to object-composition+unsub...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/object-composition?hl=en.

Op donderdag 15 maart 2012 12:56:42 UTC+1 schreef Mikey het volgende:

Hi Tom,

To unsubscribe from this group, send email to object-composition+unsubscribe@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/object-composition?hl=en.

--
You received this message because you are subscribed to the Google Groups "object-composition" group.
To view this discussion on the web visit https://groups.google.com/d/msg/object-composition/-/X-Aj1W_LjNMJ.
To post to this group, send email to object-composition@googlegroups.com.

To unsubscribe from this group, send email to object-composition+unsubscribe@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/object-composition?hl=en.

--

Trygve Reenskaug       mailto: try...@ifi.uio.no

Morgedalsvn. 5A         http://folk.uio.no/trygver/

N-0378 Oslo               Tel: (+47) 22 49 57 27

Norway

--
You received this message because you are subscribed to the Google Groups "object-composition" group.

To view this discussion on the web visit https://groups.google.com/d/msg/object-composition/-/jTbhDZD6XmcJ.