Re: Question about Prokon example

[Matthew Browne]

Hi Trygve et al.,
I asked Trygve a question about the Prokon example and I thought his reply might be of interest to some people in this group (see below). I also have a few follow-up comments/questions...

Trygve, if I understand correctly, putting the addActivity() method in the View (DependencyView) is following your original concept of MVC in the sense that MVC is a guideline rather than a strict set of rules. So although addActivity() is triggered in response to the menu command, and thus has to do with responding to user input rather than presenting things on the screen, it's better to just put it in the View in this case because it's more readable. I suppose that if it involved more than just two lines of code to delegate to the AddActivityCtx, you would have put it in the Controller instead.

This is all fine and makes sense, but I do have a suggestion which ordinarily wouldn't be worth mentioning except for the fact that the Prokon example is the most current reference implementation of MVC (and its interaction with DCI) authored by you. Readability is paramount and the code should stay as-is, but perhaps there's some comment you could add above the DependencyView.addActivity() method that would help prevent people from getting confused about MVC norms. This is still a relatively minor point; I just bring it up for posterity's sake.

BTW, before reading the MVC pattern article, I didn't think of the difference between Controllers and Views as being strictly about input vs. output (I got that idea from the article - Pattern 7). But although you may have included that pattern to incorporate the Smalltalk-80 implementation and now want to discourage that narrow conception of Controllers, it seems that input vs. output is still a key point.

Thanks,
Matt

P.S. I have been doing some exploration recently of how to make UI code more readable, in conjunction with DCI of course, and will have more to share about that soon. I imagine that will be considered more on-topic and interesting than MVC alone, but wanted to be very clear on the basics first :)

On 1/8/17 9:31 AM, Trygve Reenskaug wrote:

You're welcome to share it with anybody.
--Trygve

On 08.01.2017 14:44, Matthew Browne wrote:

Hi Trygve,
Thank you very much for the detailed reply. Is it OK if I share it with the group? I think others might find it interesting as well.

Cheers,
Matt

On 1/8/17 6:07 AM, Trygve Reenskaug wrote:

Hi Matt and a Happy and stimulating New Year to you.

It is very hard to understand MVC from what's published on the web because there is no consistent vocabulary. The confusion started with the Smalltalk-80 implementation of MVC. Their Views and Controllers came in pairs: The first for output from the computer, the second for input to it. They had missed the critical responsibility of the original Controller to coordinate several views. In my draft pattern language, I tried to clean up by defining tool to mean what I originally meant by Controller.  It didn't catch on. I've later gone back to start and ignore the ST-80 separation of input and output.

MVC separates the parts of a program that are responsible for representing the information in the system and the parts that are responsible for interaction with the user. The data that represent my mental model within the computer is called the Model. A View is responsible for presenting the Model in a way that makes it easy for me to transform the presented data into information in my brain and that helps me understand the effects of commands that I can give through the View. Some tasks may require tools that include several, coordinated views. This coordination is done by a Controller.

I don't see MVC as a straight jacked, but as an inspiration.  I let it guide my implementations, but not constrain me when other solutions are clearly more readable. addActivity in the DependencyView follows the above pattern. The View lets the user trigger the operation through a menu command. (Today, it would probably be done through by clicking a button in the View.) The operation is executed in a Context according to the DCI paradigm.

More inline below.
   

On 02.01.2017 01:03, Matthew Browne wrote:

Hi Trygve,
Happy new year!

I have a question about the Prokon example...I think it's actually more of an MVC question than a DCI question.

The DependencyView has an instance method addActivity which is called when the user chooses "Add a new activity in this plan'" from the menu. addActivity then delegates to the AddActivityCtx.

My question is whether a simple method to handle user input like this one (DependencyView.addActivity) falls under the traditional responsibility of a View in MVC.

Yes, if you mean my original work with MVC at PARC. See above.

I thought the whole point of the Controller/View separation was that the Controller handled input (user actions) whereas the View handled output (displaying things on the screen).

No. That separation was unfortunately introduced in Smalltalk-80 and has led to a lot of confusion. They lost the Controller's original responsibility as a coordinator of several views.

I do remember your MVC pattern article mentioning that the View and Controller responsibilities can be handled by the same object for simple cases; is this an example of that? But if that's true is it perhaps slightly confusing that it's still called a View in Prokon (DependencyView)?

M, V, and C are roles. A role can be played by many objects and an object can play many roles. There is a very deep distinction between objects and roles. I have seen a researcher call them form and function. He was experimenting with infants, and found they recognized this distinction before they learned to talk. With time, people seem to push this distinction into their subconscious, they merely unthinkingly use it. Example: London Transport owns many buses of different makes and specifications. (different forms). Buses serve different routes such as route 390 going from Archway to Notting Hill Gate (function). Form and Function are orthogonal characterizations Many people confuse class (form) and role (function), yet they would never confuse a particular bus with the route it happens to serve at a given time. Curious.

Sorry to bother you with a basic MVC question, but there are so many different interpretations of MVC that even after reviewing the MVC documents on your website to better understand the original concepts, I am still unclear on this point.

There are many confusing explanations of MVC out there. I use the simple one given above and ignore the rest.

Thanks,
Matt

A pleasure. Your question triggered more thoughts on the mental model of computing I'm currently working on.
--Trygve

--

The essence of object orientation is that objects collaborate  to achieve a goal.
Trygve Reenskaug      mailto: try...@ifi.uio.no
Morgedalsvn. 5A       http://folk.uio.no/trygver/
N-0378 Oslo             http://fullOO.info
Norway                     Tel: (+47) 22 49 57 27

--

The essence of object orientation is that objects collaborate  to achieve a goal.
Trygve Reenskaug      mailto: try...@ifi.uio.no
Morgedalsvn. 5A       http://folk.uio.no/trygver/
N-0378 Oslo             http://fullOO.info
Norway                     Tel: (+47) 22 49 57 27

[James O Coplien]

This is useful. I am currently writing a paper — mainly a distillation of Trygve’s comments — specifically to set the record straight in light of a terrible set of postings on DZone.

-- 
You received this message because you are subscribed to the Google Groups "object-composition" group.
To unsubscribe from this group and stop receiving emails from it, send an email to object-composit...@googlegroups.com.
To post to this group, send email to object-co...@googlegroups.com.
Visit this group at https://groups.google.com/group/object-composition.
For more options, visit https://groups.google.com/d/optout.

[Matthew Browne]

I look forward to your paper, Cope - please let us know when you publish it.

I just re-read the section about Views and Controllers in Andreas's article (Rediscovering MVC) and realized I should have revisited it sooner. Several months went by between my reading of Andreas's article and my first really thorough reading of the MVC pattern article, so I apologize for not realizing sooner that reading both articles in conjunction would answer most of my questions.

Specifically, the points I was missing were these:

- A view "can handle its own input"

- A Controller can pass commands to the Model, but doesn't have to. "Since the Views talks directly to the Model when possible, it's not required to pass any commands through the Controller. It could be required if the Controller is the only way in the framework to send requests to the server, but that's also an implementation detail."

Thanks again Andreas for your article.

So Trygve, while code comments are always helpful, my suggestion about commenting the DependencyView.addActivity() method is less important than I thought.

I am still trying to get a better sense of when it's more optimal for user input to be handled by Views vs. Controllers, or even directly by Models, but as Trygve keeps reminding us, that's more art than it is science or fixed rules. Also, the particular implementation of course depends on the particular technical requirements of a given project. And in the end it's about what best reflects the mental model and results in the most readable code.

I am curious: what is the source of the following quote from Cope:

A View can handle some of its own input (e.g., a text input field can handle all local text processing - backspaces, line kills, etc.) only to send the data to the Model when an ENTER key is pressed or a button is pushed - but that's kind of an optimization. The important is that the end users should feel as though they are interacting directly with the Model. That completes the link from the end user mind to the program and back.

Cope or Andreas - was that in private email correspondence, or is it from a message or article publicly available on the web? (Google didn't find it.)

Thanks everyone for helping me to better understand MVC as originally intended!

--Matt

[Quang]

I recently spend time to re-read all the posts here as well as all the books recommended by Cope.

Otherwise I cannot catch up with the discussion here :)

So I just picked up this conversation about the MVC/MVVM 

I just want to share the work I did recently related to the MVC/MVVM.

1) The 1st project I worked on was UI for online game.

The UI code was half in Action Script and half in C++.

So I had to cut the MVC and I did cut it at the Controller. So my view and 1/2 controller was in action script to handle input/command and forward to the other half of controller in c++.  The model was in C++ and we pass DTO to action script for the View.

It is important to mention the workflow and collaboration. The artist and UI designer work on Flash editor for prototype and the programmer integrate with the code.

The good things was:

- Flash editor was top notch UI editor.

- Action script allows us to hack around fast for prototype.

The issues was:

- Designers need to know action script to do interactive prototype, otherwise just mock-up.

Not all of them can do interactive prototype they have to wait for integration to see their UI.

- It is costly to integrate the work from designer to the code. There was many rounds back and forth.

- Designer need to use Flash editor and Game editor to test UI in game which was very tedious for them.

2) I moved to new project with new vision for UI tool chain to solve the above issues:

- Support UX designers, empower them.

- We get rid of Flash editor, to use Game Editor for UI. So that one editor can rule them all.

That meant we had to re-build what Flash Editor can do for us.

- Designers want to prototype fast in game without waiting for programmer to help to integrate.

- So We use WPF tool chain as inspiration:

+  We have tool for designer to create UI panel

+ We have tool for designer to create Storyboard

+ They can test UI with fake data, until they are happy and check in.

+ Programmer can provide real data (Model)

And this is the only real reason I found the the View Model is needed.

In WPF, the UI Editor will create an instance of the View for designer to design the UI.

But the View need the Model, that why people created the View Model as the middle layer and they can replace with fake ViewModel to preview the UI. We did the same thing for our tool chain.

This works well when we care about the UI editor.

In another story, when we do not care about the UI editor much. The ViewModel and its declarative XML become a burden.

Who wants to read and edit XAML file all day. 

How about doing data binding twice (in the XAML, and in the ViewModel) for trivial ViewModel.

Sometimes in the View Model we access the Model code directly and UI Editor cannot create the View Model which ends up with errors in the UI Editor. (the Model can access data base, network.... ). So the View need to support real and fake data mode.

In short if we need to use UI editor and fake data, MVVM and its view model is one of many solutions to do so.

Otherwise Using MVVM might end up with reading/editing a lot of XAML file and fighting with mysterious error from data-binding engine.

And Yes we can reuse the ViewModel for many View(s) (might not be at the same time on the screen).

This happens when the ViewModel contains a lot of data and each view just need some data from the View Mode.

And yes we can reuse the View too, for example the editor for Storyboard can be re-used for AI State machine, Visual Effect editor.

Because they all have the same underlying data model: State Chart. But this reuse did not come for free.

We built it first, then refactor a lot to standardize it before reuse it for 2nd editor...

I am not sure how it is done in the Web world now. Does UI designer still has to wait for programmer to see their UI?

Do we have good UI editor in the Web world now? 

It is hard to have good UX if designer cannot directly manipulate the design of the interface :)

/quang

[Matthew Browne]

Here's an exchange between Trygve and Cope on the subject of View Models from a previous thread:

On Sunday, April 24, 2016 at 8:49:05 AM UTC-4, cope wrote:

Den 24/04/2016 kl. 14.46 skrev Trygve Reenskaug <try...@ifi.uio.no>:

Just to confuse the issue: There might be a Model of the IO in addition to another Model of the substance.

I’ve heard of this only in programmers who are trying to second-guess how the other programmer might have misdesigned the interface.

I’ve never seen anything like this mentioned in Raskin, Kay, Laurel, or any of the other HCI literature I’ve come across. Is there any published cognitive research on this?

In general, I think the consensus here is that a View Model is usually an unnecessary additional abstraction that works against MVC's goal (and DCI's goal) of keeping the interface as close to the user's mental model as possible (both on the screen and in the code).

I do think there are exceptions to this...sometimes it makes sense to somewhat restructure model data for the purpose of the UI, add additional properties, etc. and a View Model can be a good solution for that as long as you're not doing any unnecessary deviations from the mental model. But looking back at my own comments in that thread, I think I failed to sufficiently emphasize that this is an exception to the general rule. For one thing, I don't think anything in regular MVC prevents the Views from having some state/data of their own, which is a simpler way to leave the Model pure.

I don't know exactly what Trygve was referring to in the above quote, but I interpreted it as an agreement that there are occasional legitimate uses for a View Model (I think Trygve's use of the term "IO" here refers to I/O in the UI). But the View Model pattern has been widely overused and is often presented in a way that shows a lack of understanding of MVC and its ability to accommodate most situations without adding additional layers. So the bottom line is to consider carefully whether a View Model is really needed...or just avoid it completely as I think Cope was advocating.

To reply to your point more specifically:

On 3/29/17 11:13 PM, Quang wrote:

+  We have tool for designer to create UI panel

+ We have tool for designer to create Storyboard

+ They can test UI with fake data, until they are happy and check in.

+ Programmer can provide real data (Model)

And this is the only real reason I found the the View Model is needed.

In WPF, the UI Editor will create an instance of the View for designer to design the UI.

But the View need the Model, that why people created the View Model as the middle layer and they can replace with fake ViewModel to preview the UI.

To me that sounds more like just having a second copy of the Model code for administrative purposes (i.e. to let UI developers work concurrently with backend developers). I wouldn't consider it a "View Model" unless it actually differs from the real Model in some substantive way. If all you're doing is shuttling data from the Model to the View Model, that just sounds like an implementation detail....although of course, it does introduce a bit more complexity, so you'd want to make sure there was a good reason for doing so. Given your team structure, it sounds like there is a good reason for it...and I would also add that it can be handy for web development given the client/server separation.

[Quang]

yep the MVVM is the alternative of MVC to support UI editor.

But the problem is many UI programmers out there not using the UI editor but still need to pay the  price for using View Model.

As its name states the View's Model actually belongs to the View and what it does is to be the Model for the View.

And it started to spread out like silver bullet to the web world, but I am not sure how the web world use it to get the benefit with the cost of xaml/binding...

And the ViewModel is used as the Controller too....Then it gets really messy :)

Anyway this is endless story, so I just wanted to share one of the real reason we wanted to use View Model, otherwise there is cost and benefit for using it....

/quang

To unsubscribe from this group and stop receiving emails from it, send an email to object-composition+unsub...@googlegroups.com.

[Trygve Reenskaug]

What's this? More precisely: What is the MVC Model?

1. It's a PNG-coded drawing. The Model is its PNG code.
2. It's a UML class diagram. The Model is a class inheritance structure
3. It's a UML class diagram. , the Model is the View objects playing roles in my BB9Planning example
4. ...

I think my BB9Planning example is relevant for the discussion. I published the example many years ago and hoped for a heated discussion of its more than discutable architecture. Nothing happened. It has been very sad for me that nobody has been willing to discuss my DCI model and implementation. I'm now working on "Programming for everybody" (PP) and explicitly except professional programmers from my target group. They'll never grok my mental model of computing because they will fanatically protect their old and outdated mindset. Hence the hatred of Smalltalk.

This is what I'm writing at the moment:

There are many initiatives for teaching programming to children.[1] Some use specialized programming environments that are optimized for the novice but do not scale to full-sized systems.[2] Other initiatives build on one of the mainstream languages such as Java, Ruby, Python. These languages are all similar in that the programmer writes a text file, the source code, and transforms it through a number of stages to code that can be fed the control unit of a von Neumann computer. This model can be found at the rock bottom of most programmers' mental model of what computing is all about.

The von Neumann computer is stand-alone; it can only communicate with other computers through its I/O devices.[3]

We believe that this well-established model should be discarded because communication is outside its scope while communication is at the forefront in Ellen's world. We feel forced to look elsewhere and land on Alan Kays original definition of object-orientation:[4] "Thus its semantics are a bit like having thousands and thousands of computers all hooked together by a very fast network.[5]

---

[1] Teach the kids coding.

[2] ST-72, e-Toys, Scratch

[3] WIKIPEDIA vonNeumann

[4] Kay history

[5] History of ST

etc, etc.

Forget von Neumann (and Turing?) and start again with Alan Kay's object computer. Internalize it by playing with BabyIDE (found in my Squeak image). Only then can we start discussing what DCI and MVC are all about and why Alan Kay's original object-orientation  should form the foundation for the mental model of computing for everybody (except the mainstream experts and scientists)

---Trygve

To unsubscribe from this group and stop receiving emails from it, send an email to object-composit...@googlegroups.com.

To post to this group, send email to object-co...@googlegroups.com.
Visit this group at https://groups.google.com/group/object-composition.
For more options, visit https://groups.google.com/d/optout.

[Quang]

Hi Trygve,

Thanks for bringing us back to the root of MVC.

When I read the MVC pattern language, I saw this:

"P-6: MODEL/EDITOR SEPARATION Context A person wants to study and interact with a business object (P-5 on page 8). Problem The user may want to inspect and edit information that exists in a business object. • These objects may not be directly accessible from the node holding the user interface • The objects may be too complex to be viewed directly • Different tasks may require different presentations and operations on the same information; each version highlighting some aspect and suppressing something else. Solution We split each Business Object into two parts; one close to the user and another close to the domain services. We call these objects Editor and Model respectively. The Model holds the user’s object model with its information and behaviour, reflecting the user’s mental model. The Editor is responsible for presentation and user operations. 

The Model can be implemented as a Facade as defined in [GOF]."

Do you have any good example for Model can be implemented as a Facade as defined in GOF.

I think that: more and more people implement the MODEL this way especially in the client/server application.

.

The ViewModel can be considered as Facade of the Domain Model.

Just curiously want to know your thoughts when you wrote that sentence.

/quang

[Trygve Reenskaug]

As I said in my msg, the root of MVC and DCI is a mental object model defined by Alan Kay. It is definitely NOT a von Neumann machine. I have in the past tried to accommodate von Neumann thinkers, but have given it up as being impossible. At 87, I'm spending my last year(s) on documenting my most important ideas. You refer to a draft pattern language from 2003. It was an invitation to a discussion that was ignored at the time. It's too late to start that discussion now because I would first have to rewrite my proposal.
--Trygve

To unsubscribe from this group and stop receiving emails from it, send an email to object-composit...@googlegroups.com.

To post to this group, send email to object-co...@googlegroups.com.
Visit this group at https://groups.google.com/group/object-composition.
For more options, visit https://groups.google.com/d/optout.

[Quang]

I actually tried out BabyIDE in smalltalk.

And that is exactly my feeling:

In smalltalk, the feeling is working with Object directly. 

- I need define object's class 1st, then I start to think about how to improve the script for the object.

- DCI in BabyIDE is even better, I start to improve the communication of the objects. Communication network becomes 1st class.

I hope the guys behind Scratch at MIT will grab this idea and continue to improve Scratch with People Programming.

I used Scratch to teach my kid programming, and I have another application on Ipad for him to play the theater game.

One day I will explain to him how to program with a theater metaphor.

In my example of how we used ViewModel, the UI editor actually tries to create the View Object(s) for designer to manipulate.

It is a small part of object machine which is available in Smalltalk all the time.

In small talk we have all the objects at hand to think. 

Back to reality: We, programmers,  are stuck in text file editor for so long because we are nerds.

And to nerds that is not hard at all, or if it is not hard enough it is not fun :)

/quang

[Matthew Browne]

Hi Trygve,
I had no idea you felt that way. I remember when you first announced your BB9Planning example (Prokon), that the initial reaction consisted mainly of comments about the Smalltalk code being difficult for most of us to read, and other side issues rather than the actual substance and DCI architecture. But I do think that many of us found the example very valuable as one of the largest and most complete DCI examples we have, and over time it has come up many times in discussions. So while I knew at the time that you must have been disappointed by the initial reaction, I thought that by now it would be clear that there is in fact interest in the example and that we all appreciate it as a major contribution.

As to the paradigm shift to a fully object-oriented computer (or at least programming with that mental model), I think there is interest here in that as well. Most of us of course carry the baggage of today's conventional programming paradigms and techniques (to varying degrees), but I remain convinced that DCI is of tremendous value to open-minded programmers even given the constraints of existing languages. And at the same time we should continue to pursue efforts that completely leave behind the Von Neumann architecture.

--
Sent from my Android device with K-9 Mail.

[Quang]

For those, still want to discuss the ViewModel and nerd based MVC, another view of MVC from nerd's view: 

https://www.infoq.com/articles/no-more-mvc-frameworks

Basically, in web world, the Client is thin View, and it requests server for data.

So it tries to request client (or view) specific data only (aka ViewModel). 

They do this to minimize the number of calls to server while keep the client thin.

/quang

[James O Coplien]

On 3 Apr 2017, at 18.19, Trygve Reenskaug <try...@ifi.uio.no> wrote:

It was an invitation to a discussion that was ignored at the time. It's too late to start that discussion now because I would first have to rewrite my proposal.

Is there anyone else who knows MVC, or will knowledge of the “real MVC” die with you?

[Trygve Reenskaug]

Funny. I refused to write an article on MVC for the special issue of Byte on the occasion of Smalltalk going public. I thought it was too obvious. So my answers are no and yes.

May be MVC will be obvious to anybody who has truly assimilated the object model as their mental foundation for computing...

Do you know why nobody ever discussed my draft MVC pattern language?

[James O Coplien]

On 5 Apr 2017, at 13.06, Trygve Reenskaug <try...@ifi.uio.no> wrote:

Funny. I refused to write an article on MVC for the special issue of Byte on the occasion of Smalltalk going public. I thought it was too obvious. So my answers are no and yes.

May be MVC will be obvious to anybody who has truly assimilated the object model as their mental foundation for computing...

Do you know why nobody ever discussed my draft MVC pattern language?

Lots. I brought it up at many fora and it was well-received.

Go plant an apple tree.

[Trygve Reenskaug]

My mistake. I thought a pattern wasn't a pattern before it was discussed and improved in a community?

--
You received this message because you are subscribed to the Google Groups "object-composition" group.
To unsubscribe from this group and stop receiving emails from it, send an email to object-composit...@googlegroups.com.
To post to this group, send email to object-co...@googlegroups.com.
Visit this group at https://groups.google.com/group/object-composition.
For more options, visit https://groups.google.com/d/optout.

[James O Coplien]

I wasn't aware you had taken it to the community.

You didn't think that it was "Build it and they will come," did you?

Sendt fra min iPhone

[Trygve Reenskaug]

No, but I thought it was presented when I presented it at a patterns conference PLoP 2012). You could have given your comments or suggested a next step, you were there.

[Quang]

MVC as a pattern language has full-filled its original vision and still continue to guide developers in UI/UX.

Everyone uses it religiously (Apple, Microsoft...)

The only thing that people disagree is the implementation of MVC fo different situations: client server, thin/thick clients, micro-services..

And just like DCI, people will try it and come back here to ask: Am I doing it correctly? Should I try this or that ? Is there any example.....

So long live MVC.

/quang

[Trygve Reenskaug]

OOPS!! I'm very sorry.  I checked and I did NOT present MVC at PloP.  It's correct that you were there, but my MVC pattern language wasn't.

No, but I thought it was presented when I presented it at a patterns conference PLoP 2012). You could have given your comments or suggested a next step, you were there.

On 05.04.2017 17:29, James O Coplien wrote: