DCI context in a web application

[Andreas Söderlund]

I'm thinking how and when a DCI context can be used in a Web application. I'm considering this high-level use case:

1. User enters city, arrival, departure, room type and clicks "Search".
   
2. System displays a list of hotels
   
3. User clicks on a Hotel logo to read its details
   
4. System displays hotel details
   
5. User clicks "Book now"
   
6. System displays payment form
   
7. User enter customer details, billing information and clicks "Submit".
   
8. System validates billing information and displays a booking confirmation.
   

This is very high-level and surely needs to be broken down. The first steps (1-2, 3-4, 5-6) feels like simple resource requests that could be handled with some search- and REST-architecture. So my first question is, is there a need for a DCI-context in those cases, isn't plain MVC enough? Of course a "Hotel" data entity could play a role, but would you consider it feasible, especially if it's the only actor?

The last step is where I see that DCI could be very useful, for now there is work to do in a procedural fashion. (Creating a Customer, adding a Booking to the Hotel, sending confirmation mail...)

What are your thoughts on this? Am I on the right track? Thank you for any comments!

/Andreas

[rune funch]

I think I would say that a context starts at step 2.

You have a list of offers that plays a part. Currently those offers are hotel offers but what's a hotel offer? they might be different things. Some might be from brokers and some might be directly from hotels those are two different types of entities but they play the same part in this context, you might have many more types some which might be contexts the self. E.g. flight and hotel combined to an offer, where in that context a hotel/broker offer and a cheap flight offer plays each a role but the the listed use case you shouldn't have to worry about this but simply make it possible for the domain to evolve independently of the use case and though the use case is book cheap hotel I'd say that the form which we are trying to capture can be expressed better (though not exact) with "find best offer"

Then when picking a specific offer I'd agree that you start a new context

Best regards

Rune

2012/10/23 Andreas Söderlund <gaz...@gmail.com>

/Andreas

--
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/-/gFgXRHXOuF4J.
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.

[Unmesh Joshi]

Hi Rune,

I think the way your are approaching the problem is that of a family
oriented approach. Categorizing hotel as 'offer' and then building
software to support multiple 'offerable' items like Hotel, Flight, Car
etc... can be done by commonality and variability analysis of booking
domain.
I am not sure if this is enough to categorize the problem as suitable for DCI.

Thanks,
Unmesh

[Andreas Söderlund]

Thank you Rune, that expanded my perspective on contexts. So when I have a list of offers, how do I use that list as a Model for display in a View? I cannot return roles because they are not valid outside a Context, and I don't know what domain objects are used behind them. 

Can a View be seen as part of a context, so rendering/displaying it inside the context is valid? Or in this case when using ASP.NET MVC, returning from the Context a ViewResult with the list of offers as model. In that way the offer role is concealed in the view, but technically, I guess it still lives outside the Context that way.

/Andreas

2012/10/23 Andreas Söderlund <gaz...@gmail.com>

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

[rune funch]

Den 23/10/2012 kl. 17.37 skrev "Andreas Söderlund" <gaz...@gmail.com>:

> valid outside a Context, and I don't know what domain objects are used behind them.

Roles are identifiers so you can no more return roles than you can
return variable names. You can however return RolePlayers if that fits
the context

[Andreas Söderlund]

Ok, so what is the difference between a Role and a RolePlayer, for example in the bank transfer example: http://horsdal.blogspot.se/2009/05/dci-in-c.html ?

[rune funch]

if we have the following code

var myFoo = new Foo();

then we have an identifier (variable name) myFoo and some object (the result of the RHS). In DCI we have a special kind of identifier called a role and a RolePlayer is simply an object assigned a role.

-Rune

2012/10/23 Andreas Söderlund <gaz...@gmail.com>

Ok, so what is the difference between a Role and a RolePlayer, for example in the bank transfer example: http://horsdal.blogspot.se/2009/05/dci-in-c.html ?

--
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/-/LK4YJL8y9YUJ.

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

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

[Jason Voegele]

On Oct 23, 2012, at 1:33 PM, rune funch wrote:

if we have the following code

var myFoo = new Foo();

then we have an identifier (variable name) myFoo and some object (the result of the RHS). In DCI we have a special kind of identifier called a role and a RolePlayer is simply an object assigned a role.

But is it not the case that what you call a role is more than just an identifier or variable name because it has some code or algorithm associated with it? For instance, the many transfer example has a role named "Source" (within the MoneyTransfer context), but this role is more than just a name because it has Withdraw and Transfer methods contained within it.

-- 

Jason Voegele

Never be led astray onto the path of virtue.

[rune funch]

2012/10/23 Jason Voegele <jason....@gmail.com>

Yes it is the case which is what makes it a role and not just another variable but it's still "just" an identifier. It identifies the RolePlayer when the contexst executes and it identifies the RoleMEthods associated with the RolePlayer (while playing the role)

-Rune

 

-- 

Jason Voegele

Never be led astray onto the path of virtue.

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

[James O Coplien]

Andreas Söderlund is playing the role of a mailing group member.

Andreas Söderlund is, at his foundation, a lump of DNA.

A mailing group member, in the current Context of dialogues, exhibits behaviors of asking questions through mails.

What is the difference between a mailing group member and Andreas Söderlund? In the context of the current Context: nothing. In general, equating them is a category error.

On Oct 23, 2012, at 10:31 , Andreas Söderlund wrote:

Ok, so what is the difference between a Role and a RolePlayer, for example in the bank transfer example: http://horsdal.blogspot.se/2009/05/dci-in-c.html ?

--
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/-/LK4YJL8y9YUJ.

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

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

[Raoul Duke]

in other words: role = interface, roleplayer = concrete implementer of
interface.

?

[rune funch]

Den 23/10/2012 kl. 20.56 skrev Raoul Duke <rao...@gmail.com>:

> in other words: role = interface, roleplayer = concrete implementer of
> interface

A role is not an interface any more than a variable name is an
interface for the object it represents at runtime. A role is an
identifier it identifies a RolePlayer and the role specific behavior
of said RolePlayer. Interfaces are a subset of types. Identifiers are
not.
This is a form of class thinking. In DCI we are more concerned with
objects that types. Roles tells us something about the objects
behavior at runtime but nothing about its type whereas interfaces
tells us something about the type at compile type but little about the
type of the object at runtime

[Raoul Duke]

On Tue, Oct 23, 2012 at 12:49 PM, rune funch <funchs...@gmail.com> wrote:
> This is a form of class thinking. In DCI we are more concerned with
> objects that types. Roles tells us something about the objects
> behavior at runtime but nothing about its type whereas interfaces
> tells us something about the type at compile type but little about the
> type of the object at runtime

different semantics, connotations, for the terms used?

if you mean e.g. roles are structural types and not nominal, you'd
still have the word 'type; involved. :-)

er, unless you are really trying to come up with new ways to have even
more runtime exceptions than the run of the mill "dynamic" "scripter"
programmer. :-)

[Risto Välimäki]

Not semantics, but roles are not types at all.

You mean role contracts here. Role contracts may be types. Role contract is more or less an "interface" that an object has to fullfil to be able to play a certain role in a certain context.

-Risto

2012/10/23 Raoul Duke <rao...@gmail.com>

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

[Raoul Duke]

On Tue, Oct 23, 2012 at 1:20 PM, Risto Välimäki
<risto.v...@gmail.com> wrote:
> Not semantics, but roles are not types at all.
> You mean role contracts here. Role contracts may be types. Role contract is
> more or less an "interface" that an object has to fullfil to be able to play
> a certain role in a certain context.

so Role Contract is the in-the-code implementation artifact of the
outside-the-computer generalized domain idea of Role? like you can use
Role in engrish w/out having to mention anything about computers.

[rune funch]

2012/10/23 Raoul Duke <rao...@gmail.com>

if you mean e.g. roles are structural types and not nominal, you'd
still have the word 'type; involved. :-)

No I mean that they are not a type but an identifier. Being an identifier a role is no more a type than a variable name or a parameter is a type.

 

so Role Contract is the in-the-code implementation artifact 

Role contracts are not something you implement. In certain languages (such as Marvin) they can be specified. 

It's a contract that an object must fulfill to be able to play a specific role. Not doing so will lead to a compile time or runtime error (depending on the language used). (Method not implemented)

[Risto Välimäki]

If I understood correctly, no.

But with real world language:

Edwin Booth was an actor, an Object.

Hamlet is a Role in play Hamlet, which is the Context here.

Hamlet WAS not Edwin Booth and Edwin Booth WAS not Hamlet.

Still Edwin Booth had all what is needed to Play Role of Hamlet in Hamlet Context.
In another words, Edwin Booth fulfilled the Role contract for Role Hamlet in Hamlet Context.

Also Edwin Booth actually played successfully Role of Hamlet in Hamlet Context, so he really was a Role player.

I hope this helps.

-Risto

2012/10/23 Raoul Duke <rao...@gmail.com>

On Tue, Oct 23, 2012 at 1:20 PM, Risto Välimäki

[Risto Välimäki]

I think I have to add notion on Role methods here, because that may be an another source of confusion:

While Roles are only identifiers, inside Contexts there are usually Role methods which are Just-On-Time -- temporarily -- attached to Roleplayers which are identified by Roles.

But while Role methods they are attached to Roleplayers (that are identified by Roles), you can never return a Roleplayer with Role methods attached from a Context to another. If your implementation style (injectionless, method injection, wrapper, etc.) allows that, you are in serious problems.

-Risto

2012/10/23 Risto Välimäki <risto.v...@gmail.com>

[Rickard Öberg]

On 10/23/12 18:20 , Andreas S�derlund wrote:
> I'm thinking how and when a DCI context can be used in a Web
> application. I'm considering this high-level use case:
>

> 1. User enters city, arrival, departure, room type and clicks "Search".
> 2. System displays a list of hotels
> 3. User clicks on a Hotel logo to read its details
> 4. System displays hotel details
> 5. User clicks "Book now"
> 6. System displays payment form
> 7. User enter customer details, billing information and clicks "Submit".
> 8. System validates billing information and displays a booking

> confirmation.
>
> This is very high-level and surely needs to be broken down. The first
> steps (1-2, 3-4, 5-6) feels like simple resource requests that could be
> handled with some search- and REST-architecture. So my first question
> is, is there a need for a DCI-context in those cases, isn't plain MVC
> enough? Of course a "Hotel" data entity could play a role, but would you
> consider it feasible, especially if it's the only actor?

The way I've done it in webapps, the logic is implemented by a REST API
that only uses DCI for its implementation. Each /foo/ becomes a context,
and within that context is a number of queries and commands (e.g.
/foo/search and /foo/book, note the lack of / here which indicates that
it is not a usecase but an interaction), which can lead to subcontexts
/foo/bar/, having its own queries and commands. From the root / you
would then get hypermedia showing all usecases, and then from each /foo
you get hypermedia with links to what you can do within that usecase,
and that can then be used to drive the application state, just as Roy
intended it. It is teh awesome, and suddenly this whole linking thing
becomes obvious. A good REST API should be like an ugly website, is my
rule of thumb.

One the client side you can then either have a webapp that uses MVC, or
a rich client in Javascript or whatever that uses this. I've done both,
and the unified REST backend really helps.

/Rickard

[James O Coplien]

On Oct 23, 2012, at 1:20 , Risto Välimäki wrote:

Not semantics, but roles are not types at all.

I guess it depends what you mean by "type." I think they are indeed types. Why don't you?

[rune funch]

Den 24/10/2012 kl. 05.10 skrev James O Coplien <jcop...@gmail.com>:

On Oct 23, 2012, at 1:20 , Risto Välimäki wrote:

Not semantics, but roles are not types at all.

Because the use of the term 'type' that most people have do not coincide with the use used in type theory. Conceptually you don't instantiate roles nor can you cast an object to 'Role x'. In some language that do not support DCI that well you will have to but that because you have to not because the role concept enforces this ability. 

When assigned to a role the type of the object changes but this new type is a union of the type of the object and the role is neither on their own. I find that trying to use the more academic version of 'type' though correct confuses more that it helps because it is more likely to keep people in class based thinking

I guess it depends what you mean by "type." I think they are indeed types. Why don't you?

--

[try...@ifi.uio.no]

A view is an object, so a view can play a role. In othe view role metho
actually updates the view, This is more direct than using the observer
pattern, for example.

>> 2012/10/23 Andreas S�derlund <gaz...@gmail.com <javascript:>>

>>
>>> I'm thinking how and when a DCI context can be used in a Web
>>> application.
>>> I'm considering this high-level use case:
>>>

>>> 1. User enters city, arrival, departure, room type and clicks
>>> "Search".

>>> 2. System displays a list of hotels
>>> 3. User clicks on a Hotel logo to read its details
>>> 4. System displays hotel details
>>> 5. User clicks "Book now"
>>> 6. System displays payment form

>>> 7. User enter customer details, billing information and clicks
>>> "Submit".
>>> 8. System validates billing information and displays a booking

>>> confirmation.
>>>
>>> This is very high-level and surely needs to be broken down. The first
>>> steps (1-2, 3-4, 5-6) feels like simple resource requests that could be
>>> handled with some search- and REST-architecture. So my first question
>>> is,
>>> is there a need for a DCI-context in those cases, isn't plain MVC
>>> enough?
>>> Of course a "Hotel" data entity could play a role, but would you
>>> consider
>>> it feasible, especially if it's the only actor?
>>>
>>> The last step is where I see that DCI could be very useful, for now
>>> there
>>> is work to do in a procedural fashion. (Creating a Customer, adding a
>>> Booking to the Hotel, sending confirmation mail...)
>>>
>>> What are your thoughts on this? Am I on the right track? Thank you for
>>> any comments!
>>>
>>>
>>> /Andreas
>>>
>>> --
>>> 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/-/gFgXRHXOuF4J.
>>> To post to this group, send email to

>>> object-co...@googlegroups.com<javascript:>
>>> .

>>> To unsubscribe from this group, send email to

>>> object-composit...@googlegroups.com <javascript:>.

>>> 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/-/les30SNaDcAJ.

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

> object-composit...@googlegroups.com.

[try...@ifi.uio.no]

I am learning to use i-pad. Default automatic error correction was on, so
it tried to change my English words into Norwegian. This feature is now
off, so I try again.

A view is an objext, so it can play a role. Indeed, inone of my examples
I let the view role method update the view. Much more direct than using

the observer pattern, for example.

>> 2012/10/23 Andreas S�derlund <gaz...@gmail.com <javascript:>>

>>
>>> I'm thinking how and when a DCI context can be used in a Web
>>> application.
>>> I'm considering this high-level use case:
>>>

>>> 1. User enters city, arrival, departure, room type and clicks
>>> "Search".

>>> 2. System displays a list of hotels
>>> 3. User clicks on a Hotel logo to read its details
>>> 4. System displays hotel details
>>> 5. User clicks "Book now"
>>> 6. System displays payment form

>>> 7. User enter customer details, billing information and clicks
>>> "Submit".
>>> 8. System validates billing information and displays a booking

>>> confirmation.
>>>
>>> This is very high-level and surely needs to be broken down. The first
>>> steps (1-2, 3-4, 5-6) feels like simple resource requests that could be
>>> handled with some search- and REST-architecture. So my first question
>>> is,
>>> is there a need for a DCI-context in those cases, isn't plain MVC
>>> enough?
>>> Of course a "Hotel" data entity could play a role, but would you
>>> consider
>>> it feasible, especially if it's the only actor?
>>>
>>> The last step is where I see that DCI could be very useful, for now
>>> there
>>> is work to do in a procedural fashion. (Creating a Customer, adding a
>>> Booking to the Hotel, sending confirmation mail...)
>>>
>>> What are your thoughts on this? Am I on the right track? Thank you for
>>> any comments!
>>>
>>>
>>> /Andreas
>>>
>>> --
>>> 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/-/gFgXRHXOuF4J.
>>> To post to this group, send email to

>>> object-co...@googlegroups.com<javascript:>
>>> .

>>> To unsubscribe from this group, send email to

>>> object-composit...@googlegroups.com <javascript:>.

>>> 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/-/les30SNaDcAJ.

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

> object-composit...@googlegroups.com.

[Unmesh Joshi]

I was going through this thread again. And I think that the answers to
original questions were not specific. Considering 'hotel', 'flight'
etc.. as offers is a standard solution of the product owner building
the website wants customers to book various things related to his/her
trip (Hotel, Flight, Cars, Cruise etc..). Finding commonality and
variabilities in all the offerable items and then chosing code
constructs to fit types of variabilities is a problem that can be
solved without DCI. Standard generalization/specilization and other
techniques of classical OO will solve that problem. (A rule of thumb
is to remove if-else with message passing to objects).

DCI helps specifically in cases where there is commonality in
behaviour. Methodful Roles capture commonality in algorithms and then
object behavioral contract is composed by assigning roles to object in
a specific use case context.

The use case in the original question what a very high level (summary
level) use case. I dont see any methodful roles in this particular use
case. Nor can I see any role specific behaviour. So it is too early
to say if we can apply DCI to this specific use case. Please correct
me if I am missing something.

Thanks,
Unmesh

[rune funch]

Den 03/11/2012 kl. 12.52 skrev Unmesh Joshi <unmes...@gmail.com>:

> So it is too early
> to say if we can apply DCI to this specific use case. Please correct
> me if I am missing something

Any network of Interacting objects can be modeled as a context. So we
can use DCI

[Eric Steen]

Just to throw an example out there..

In the authentication context, a User might interact with an Authenticator. In the post commenting context, a user may interact with PostCommentPublisher(who may interact with an editor-- and editor may interact with a ProfanityMasker).

The corresponding metaphors could be a guard at an office building who checks your identity before allowing access, and a traditional publishing house with its various roles.

Sent from my iPhone

[James O Coplien]

On Nov 3, 2012, at 5:10 , Eric Steen wrote:

> In the authentication context, a User might interact with an Authenticator. In the post commenting context, a user may interact with PostCommentPublisher(who may interact with an editor-- and editor may interact with a ProfanityMasker).

These sound a bit like functors rather than roles. Other than "Authenticate," what are the methods of an Authenticator?

As someone who has written many books I can tell you I have never met an Authenticator, PostCommentPublisher or a ProfanityMasker. Authenticate and ProfanityMasking may be tasks of an Editor. There's at least some kind of mismatch going on between your mental model and mine, and the mismatch may extend into your embracing of the DCI paradigm, but I'm not sure.

[Eric Steen]

Other than "Authenticate," what are the methods of an Authenticator?

Perhaps the Authenticator assumes the role of an oauthable(social auth). Given those behaviors it can auth via social media?

Sent from my iPhone

[James O Coplien]

On Nov 3, 2012, at 7:49 , Eric Steen wrote:

Other than "Authenticate," what are the methods of an Authenticator?

Perhaps the Authenticator assumes the role of an oauthable(social auth). Given those behaviors it can auth via social media?

This is an imprecise answer and I can't place it in a DCI context. Are you saying that a role takes the role of another role? 

[Eric Steen]

This is an imprecise answer and I can't place it in a DCI context. Are you saying that a role takes the role of another role? 

Probably just a bad example. I was assuming that Authenticator object was the actualizer of a Use Case(a context), which acted upon the User( a dumb data object). Maybe if I give Authenticator a name like AuthenticationContext it is clearer?

Sent from my iPhone

[James O Coplien]

On Nov 3, 2012, at 8:55 , Eric Steen wrote:

Probably just a bad example. I was assuming that Authenticator object was the actualizer of a Use Case(a context), which acted upon the User( a dumb data object). Maybe if I give Authenticator a name like AuthenticationContext it is clearer?

Precision and clarity are worth their weight in gold here. Code doesn't lie (if it compiles). Can you give a code example?