MVC

[Matthew Browne]

I have used some variation of MVC in every system I have worked on, and have learned much in the past few years as I became more interested in the historical roots of OO, MVC, and of course DCI. But even after all of that, I still do not have a completely clear picture of how MVC was used by Trygve and others when he originally invented it. Among Trygve's articles, the most helpful was his MVC pattern language:

http://folk.uio.no/trygver/2003/javazone-jaoo/MVC_pattern.pdf

One thing I had not read until just now was Trygve's original article (I think this was the first?) about MVC:
http://folk.uio.no/trygver/1979/mvc-1/1979-05-MVC.pdf

That article is definitely informative, but it doesn't contain any code examples and it still leaves me with some questions.

For example, as originally conceived, how should the MVC programmer organize Controllers? Some developers apply MVC at the level of individual components - each UI component (for example a drop-down list or calendar component) has its own view and controller. Other developers create a Controller for each screen or page, and that controller takes care of all communication from the Model to each of the Views for that screen. And of course it's also common to have both controllers for individual components and a supervising controller for the screen as a whole. My current opinion is that each of these approaches has its place, depending on the specifics of the environment and how much functionality is provided by the UI library being used. But I would like to know how Trygve originally conceived it and whether there are any published materials where I can learn more about the specifics.

Trygve's DCI Prokon example is of course a great example of MVC in action, so perhaps I should just use that as my model (lower case "m"), but I thought it would be worth raising the above points here to hopefully get some clarification.

~~~

Andreas's Article

Last December Andreas posted a link to a nice article he wrote discussing the history of MVC:
https://github.com/ciscoheat/mithril-hx/wiki/Rediscovering-MVC

That article actually goes a long way toward answering some of my questions, and I thank Andreas for writing it. It also prompts me to ask some additional questions...

While the article is a great survey of the original MVC concepts it also seems to add an additional principle of its own: that a View must be a user-defined object. The article suggests that a DOM element in a web page constructed from a template that generates HTML doesn't count as a View. The article states that the View should be an object, and I agree with that, but that still seems pretty open-ended to me. I think most web frameworks provide some sort of object for each View; they just have different approaches to how those view objects get created (including different approaches to templating) and how many additional methods they provide beyond what the DOM itself provides (if any). The Mithril framework provides a clear place to define a view and its HTML programmatically, which has certain advantages, but the article sort of implies that Mithril is one of the few web frameworks that implements true MVC which I don't think is really true.

Also, the article makes some valid criticisms of unnecessarily introducing a "View Model", but I think a View Model can also be quite useful in cases where translation from the Model to the data properties needed by the Views is more complex (i.e. additional view-specific properties that don't belong in the real Model). Andreas, I suspect you might agree that View Models still have their place. I'm just looking to confirm that, and I'd also be interested in hearing anyone else's opinions on View Models.

~~~

Thanks in advance for suggestions for further learning about MVC.

[Hai Quang Kim]

Prokon should be the canonical example for MVC and DCI. 

(and its background story should be mentioned time to time, since it was the context for MVC)

Same for me when I read this: http://folk.uio.no/trygver/2003/javazone-jaoo/MVC_pattern.pdf

The MVC is not a design pattern, it is a solution for an organization.

I have been learning MVC without the story behind it.

I saw this paper before but just recently spend decent time with it.

Of course now a day our organization might be different.

But the inspiration from Prokon and MVC will help us a lot.

The idea is focus on people and how they want to interact with machine not the other way.

We have been writing software that force people to use it in very specific way.

That explains why UX becomes more and more important.

We need UX for application (easy to use), for code (easy to understand), UX for library (easy to  use), UX for domain services (easy to integrate)....

/quang

[Matthew Browne]

On 4/23/16 6:19 AM, Hai Quang Kim wrote:

The MVC is not a design pattern, it is a solution for an organization.

I obviously still have a lot to learn about patterns, but I don't think this is true. I get what you're saying - Trygve's original MVC solution was very much focused on the needs of a particular organization - but I think all patterns start out as a solution for a specific problem, and then people discover that the same approach can be successfully used elsewhere, and over time it becomes a pattern. I read somewhere (I think on this list) that MVC actually meets the definition of a pattern where many so-called design patterns do not, in part because of its focus on organizations and people, which has shown to be generalizable to many organizations.

The idea is focus on people and how they want to interact with machine not the other way.

This is a very important point. My post was mostly asking about technical details, but this is what most interests me about MVC and should be the backdrop to any conversation about it - thank you for stating it. And thanks for the reminder that programmers are users too :)

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

[Hai Quang Kim]

not "design pattern" like GOF and obviously they are not pattern by Alexander's definition as it was mentioned before :)

/quang

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

[James O Coplien]

Den 23/04/2016 kl. 12.54 skrev Matthew Browne <mbro...@gmail.com>:

I obviously still have a lot to learn about patterns, but I don't think this is true. I get what you're saying - Trygve's original MVC solution was very much focused on the needs of a particular organization - but I think all patterns start out as a solution for a specific problem, and then people discover that the same approach can be successfully used elsewhere, and over time it becomes a pattern. I read somewhere (I think on this list) that MVC actually meets the definition of a pattern where many so-called design patterns do not, in part because of its focus on organizations and people, which has shown to be generalizable to many organizations.

Some things work in nature; some don’t. Along the way different cultures adapt or exapt natural forms to solve the complex problems in their environs in a way that taps into these deeper natural invariants. Raised to a cultural (contextualized) level, we call the building blocks beneath those forms, patterns.

Patterns are just the individually assessable steps in longer structured sequences that individually build, refine, or integrate parts. Individual patterns in and of themselves have limited payoff: the payoff comes in the combination. Certain combinations work; others don’t. A pattern language describes how to combine small sets of patterns in working relationships. Think of it as a generative grammar whose elements are patterns.

The MVC document that Trygve wrote is a pattern language, written in a pattern language workshop that we ran in Oslo back around 2003. The language captures a way of structuring the relationships between individuals, organisations, and the software they both build and use, in a way that minimizes the energy it takes to make the system Whole and to generate and grown The Nameless Quality (匿名质量 — Quang, you’ll recognize this from the “道德经” which deeply inspired Alexander). Writing them down is just discovering the latent patterns that were there. Patterns are never invented and forms don’t really “become” patterns — they reflect forms that are closer to laws of nature.

Because this notion of language is missing from the GOF book, there is not a single pattern in that book (http://stackoverflow.com/questions/12981021/are-there-any-patterns-in-gof).

By the way, Quang — that a structure relates to the form of organisations doesn’t exclude it from being a pattern. Much of modern anthropology is build on patterns described by Kroeber in the early 1900s, which continued to persist as staples in the anthropological literature well into the 1960s. Much of my own recent pattern work is focused on such forms; see http://scrumplop.org.

[Matthew Browne]

Cope, I just found an old post by Risto saying that you once wrote "DCI is a pattern language". Would you still say that today, and if so, do you think it might be helpful to document some of the specific patterns we view as essential to DCI? Perhaps that would be more helpful for explaining DCI than attempting to write a set of DCI axioms as we did earlier.

[Matthew Browne]

On 4/23/16 8:15 AM, Matthew Browne wrote:

Cope, I just found an old post by Risto saying that you once wrote "DCI is a pattern language". Would you still say that today, and if so, do you think it might be helpful to document some of the specific patterns we view as essential to DCI? Perhaps that would be more helpful for explaining DCI than attempting to write a set of DCI axioms as we did earlier.

I should have finished reading the rest of Risto's thread before hitting Send... I see that you were already working on a pattern language for DCI back in 2009. What is the current status of that?

Thanks,
Matt

[James O Coplien]

Den 23/04/2016 kl. 14.15 skrev Matthew Browne <mbro...@gmail.com>:

Cope, I just found an old post by Risto saying that you once wrote "DCI is a pattern language". Would you still say that today, and if so, do you think it might be helpful to document some of the specific patterns we view as essential to DCI? Perhaps that would be more helpful for explaining DCI than attempting to write a set of DCI axioms as we did earlier.

I actually had started writing it up but stalled several years ago. It may come to the top of my stack in the future but I’m not sure when. Right now I’m trying to 1. keep up with the compiler and 2. get the word out at conferences (also to try to generate some business, as my illness has caused the till to get a bit dry).

The right place to do this would be at a forum (such as a conference) where we assembled a group of people to draw on a large set of historic insights.

[Matthew Browne]

On 4/23/16 8:27 AM, James O Coplien wrote:
> The right place to do this would be at a forum (such as a conference)
> where we assembled a group of people to draw on a large set of
> historic insights.

Yes, this could be a good workshop for a DCI conference...which is only
an idea at this point, but it would be better to wait than to attempt
such a thing over email. I'm guessing that the patterns you listed in
2009 were never formalized to the point of being ready to release
publicly to this group?

[James O Coplien]

> Den 23/04/2016 kl. 14.44 skrev Matthew Browne <mbro...@gmail.com>:
>
> I'm guessing that the patterns you listed in 2009 were never formalized to the point of being ready to release publicly to this group?

That’s more or less correct.

[Hai Quang Kim]

That explains why that paper is so important. It tells the story and how all the pieces work together.

People talk about the technical part of the MVC a lot (really a lot) but not many have the chance to hear the story and the original inspiration. 

Thank you very much for sharing all of this.

/quang

[Matthew Browne]

On 4/23/16 9:27 PM, Hai Quang Kim wrote:

People talk about the technical part of the MVC a lot (really a lot) but not many have the chance to hear the story and the original inspiration. 

+1. I see this all the time. Very few people in the larger community have any idea that MVC is about people, mental models, and bridging the gap between people and computers. Much as I value the aim of helping people to understand and appreciate DCI, I think that even without DCI, a better understanding of the real purpose of OO and MVC would go a long way toward improving software and the experience of those who use and develop it. I would like to do more than just lament this state of affairs, but the best I can offer at the moment is my hope that the great work and insights of Trygve and Cope, as well as the ongoing community efforts of this group will make their way to teachers of future generations of programmers, and also of course to those among the current generation who are open-minded and interested in trying a different approach. In my experience describing DCI to friends and colleagues, I find many people are very interested and receptive to it, so I think it may be largely a matter of exposing people to the ideas and history in a way that allows them to see their true value and relevance...which is of course a large part of what we're all doing here.

[Trygve Reenskaug]

+1

--

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.

--

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]

Den 24/04/2016 kl. 03.59 skrev Matthew Browne <mbro...@gmail.com>:

to it, so I think it may be largely a matter of exposing people to the ideas and history in a way that allows them to see their true value and relevance..

That’s much of what the pattern community aspire[sd] to do. I’m not sure it’s a total success because even a lot of them don’t “get it."

[James O Coplien]

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

I'm just looking to confirm that, and I'd also be interested in hearing anyone else's opinions on View Models.

To me, it’s a way to break the loop between the end-user mental model and the interface, which leads to surprises. These kinds of surprises aren’t nice. It seems to violate the Direct Manipulation Metaphor. See Laurel’s Computers as Theatre.

[Matthew Browne]

On 4/24/16 6:07 AM, James O Coplien wrote:

To me, it’s a way to break the loop between the end-user mental model and the interface, which leads to surprises. These kinds of surprises aren’t nice. It seems to violate the Direct Manipulation Metaphor. See Laurel’s Computers as Theatre.

I can see how it could be problematic, especially if the view model becomes a substitute for the real model where connecting directly with the real model would have worked fine. That leaves the question of how else to deal with additional or derived properties needed for the View that aren't part of the Model.

The "Tool as a Composite" and "Synchronize Selection" patterns offer one approach: store the view-specific data in the Controller; the Controller updates all the relevant Views when changes occur. A downside is that that seems to preclude the use of the "Synchronize Model and View" pattern for such view data.

If one wishes to use "Synchronize Model and View", then I can think of two ways of handling view-specific data:

1. If the property is directly derived from the Model in some way (e.g. the result of an operation on one or more Model properties), implement these properties as methods of the Model object(s) and ensure that the model-view synchronization can handle functions in addition to raw data.

2. Set up the model-view synchronization to use a combination of Model objects and additional properties or anonymous objects for the view-specific data.

The View Model approach is very similar to #2, except it adds an additional level of indirection (which of course is usually a bad thing unless it's unavoidable). But the model-view synchronization is automatic, so unless the underlying synchronization mechanism has bugs, I think it still provides an illusion of direct manipulation to the user. Martin Fowler describes some considerations for using a View Model (which he calls a Presentation Model) here, but I don't find them particularly convincing.

But I do think it makes sense to group data properties/functions needed for the UI in a logical way, and without a View Model you can't add view-specific properties to a data object without polluting your Model and would instead need to store them somewhere else in your hierarchy of view data. For example:

products
..0
....id: 1
....name: Medium T-Shirt
....price: 20.00
.... ...
....markedForDeletion: true

versus:

productIdsMarkedForDeletion
..1

products
..0
....id: 1
....name: Medium T-Shirt
....price: 20.00
.... ...


I'm willing to be convinced that the added layer of synchronization needed for a View Model is enough to warrant avoiding it completely even in such cases. But I don't fully grasp that perspective, and I don't see why a View Model is necessarily against the spirit of MVC and the direct manipulation metaphor.

[Matthew Browne]

BTW, Trygve and Cope, do you have any opinions or experience to share
regarding immediate mode GUIs? Egon gave an example of one here:

https://groups.google.com/d/msg/object-composition/H8_K1TUBbuE/qind9g-aAwAJ

[Matthew Browne]

I wonder if it would make sense for view-specific properties to be implemented as role methods on the Model objects. Given the current access restrictions of roles, that would of course require that those role methods and all the Views for a given screen are defined within the same Context. In any case, such properties, whether implemented as role methods or not, should of course only be accessible to the UI.

[James O Coplien]

Den 24/04/2016 kl. 13.17 skrev Matthew Browne <mbro...@gmail.com>:

That leaves the question of how else to deal with additional or derived properties needed for the View that aren't part of the Model.

Er, why not put them in the View?

[James O Coplien]

Den 24/04/2016 kl. 13.17 skrev Matthew Browne <mbro...@gmail.com>:

The "Tool as a Composite" and "Synchronize Selection" patterns offer one approach: store the view-specific data in the Controller; the Controller updates all the relevant Views when changes occur. A downside is that that seems to preclude the use of the "Synchronize Model and View" pattern for such view data.

In other words, it’s not MVC.

[Matthew Browne]

That works if you only need to show that data in one view, but not multiple views.

[James O Coplien]

The devil is in the details. I would have to see the real pixel-for-pixel GUI for the following conceptualisation below before drawing any conclusions; without it, any conclusion is premature. (Talking about MVC without showing the interface is kind of like dancing about architecture.)

As I understand you, this use case sets up a mode. “Marking something for deletion” is simply a bad idea unless the interface brings that “marking” into the end user locus of attention, and keeps it there. Most GUIs I’ve seen will allow the user to mark multiple items for deletion and then, upon exiting that page, will ask the user for confirmation that the following N items will be deleted. Because of habit formation the confirmation becomes useless. And because it’s modal it is a less productive interface (i.e., it is more likely to lead to bad input than a non-modal interface).

It’s usually better to delete the item immediately and to provide a good undo facility. There’s a bunch of cognitive theory about this that relates to consciousness, the concept of self, the limits of short- and long-term memory, and the penchant for habit formation. Raskin surveys the foundations well in his “Humane Interfaces” book.

I have a hunch that the people who are adding view models in an MVC framework. don’t fully appreciate the direct manipulation metaphor or the roles of different parts of MVC. There are still lots of people, for example, who direct all user input through the Controller instead of reasonably having screen inputs come in through the Model. That indeed distances the Model from the User and I can just imaging someone needing another level of Controller to have to manage that.

Den 24/04/2016 kl. 13.17 skrev Matthew Browne <mbro...@gmail.com>:

But I do think it makes sense to group data properties/functions needed for the UI in a logical way, and without a View Model you can't add view-specific properties to a data object without polluting your Model and would instead need to store them somewhere else in your hierarchy of view data. For example:

… like in the View.

[James O Coplien]

Den 24/04/2016 kl. 13.49 skrev Matthew Browne <mbro...@gmail.com>:

That works if you only need to show that data in one view, but not multiple views.

I don’t understand. Either itøs part of the end-usr mental model and it’s in the Model object (hence the catchy name) or it’s an artifact of presentation and belongs in the View. One maybe has to replicate the information among views — but if you do that, you violate not only modality as I pointed out in the previous mail, but you violate monotony as well.

I’m starting to get a hunch that they need to do these things comes from poor UX design.

[Trygve Reenskaug]

--

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

[Matthew Browne]

The markForDeletion example was just a quick example off the top of my head, and I now realize it wasn't a very good one. I should have thought of an example where there would be an actual need to synchronize the property across multiple views. In the case of deleting items, I agree; I wouldn't want to have multiple views showing pending deletion as that would be confusing, and while I think marking multiple items for deletion can sometimes make sense, I wouldn't want to do it in a long scrollable list where the user couldn't visually see all the selected items in one place.

I could probably think of an example from past experience that would be better for this discussion, and I may do that. But mainly I will keep your points in mind and try to avoid the use of a view model the next time I encounter such a situation. Your responses are gradually convincing me that view models may indeed be ubiquitously unnecessary when doing proper UX design and MVC. Thank you for your comments; much appreciated.

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

[James O Coplien]

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?

[James O Coplien]

Den 24/04/2016 kl. 14.45 skrev Matthew Browne <mbro...@gmail.com>:

The markForDeletion example was just a quick example off the top of my head, and I now realize it wasn't a very good one. I should have thought of an example where there would be an actual need to synchronize the property across multiple views. In the case of deleting items, I agree; I wouldn't want to have multiple views showing pending deletion as that would be confusing, and while I think marking multiple items for deletion can sometimes make sense, I wouldn't want to do it in a long scrollable list where the user couldn't visually see all the selected items in one place.

I know, and appreciate that. But I think many programmers give such issues just about as much thought before jumping into code, and end producing disasters. We have an abundance of empirical evidence that might be so...

[Trygve Reenskaug]

I never know what to answer when I get questions about MVC.

• MVC is more than a class library because it can give rise to several, different class libraries.
• MVC is more than a role model, because several, different role models could describe MVC. I've had MVC implementations where M, V, and C where all played by the same object.
  
• MVC is more than a pattern language because it could give rise to several, different languages.
• MVC is an idea, not a recipe. So what should I answer? It is very fuzzy.
  

I think I once wrote a long mail about the MVC background. There's no way I could find it now. I started the Prokon project around 1980.  Its goal was to support a business organization with  distributed authority and responsibility. Each manager should be given their personal  (virtual) computer with programs they could understand and possibly write. The first example was a distributed planning system where each manager could shape  their planning program to fit their particular needs. The overall plan was distributed among these computers and integrated through communication between them. (The Prokon project stopped abruptly when our sponsor's main customer went bankrupt.)  At PARC, I concentrated on the part-problem of a manger working with a plan that could potentially consist of several hundred activities. The novel direct manipulation interfaces that were possible through the Alto computer and Smalltalk programming environment made for a fun project.

The current thoughts in Alan Kay's group was that objects should be visible and tangible.  I faced the problem that there an activity should be made visible in many different ways. There was also the problem of making structures of related activities visible on the screen. I had always been a fan of separation of concerns. In particular, I advocated that there should be a separation between the UI part of the program and the part with the actual subject matter (a Plan, a Ledger, an Inventory...) With this separation, programs could be run by other programs as well as by humans. The first MVC implementation was a concrete program design I made at at PARC. It had an elaborate separation of concerns. People got exited about it, possibly because they saw it was more fundamental than I realized at the time.

I have written many programs through the years that are based on MVC. They no longer exist and can't be used as illustrations. Almost all of them use the GOF Observer Pattern to link the model with the I/O. In my big MVC/DCI planning example, the Subject is the Model. It is implemented as a fuzzy kind of simulated database. Whenever this Model is changed, it sends an update-message to all its observers. In this case the Controller object is the only observer. The Controller knows all the Views and can do "the right thing" with its Views. The separation of concerns is pretty deep: The Model doesn't know the I/O objects apart from its list of observers and only the Controller knows the Model. (In this example, the I/O and Model parts are further decomposed separately according to the DCI paradigm.)

Things take time. I'm still working on my 1980 vision. MVC and DCI mark steps on the way. I hope Personal Programming will be the next. But I first want to redesign Pong to fit my own idiosyncrasies.

[Trygve Reenskaug]

Of course not. I'm just a simple software designer.  What I want to suggest is the the MVC space is a very large space and that each problem has to be solved on its own premisses.

[James O Coplien]

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

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?

Of course not. I'm just a simple software designer.  What I want to suggest is the the MVC space is a very large space and that each problem has to be solved on its own premisses. 

The problem I’m hinting at is larger than MVC. Independent of MVC, Laurel makes an argument based on both the programmer and end-user trying to intuit (or second-guess) what the other is doing, and notes that it’s a hopeless loop. The example of augmenting MVC to include a “model of view” reifies the concern of her argument. I’m not at all concerned about violating “the rules of MVC” if there be such. It goes deeper into the sociopsychological problem of managing the shared perception of a model by the programmer and the end user.

[Matthew Browne]

Hi Trygve,
Thank you for your helpful explanation of some important context and background.

On 4/24/16 8:57 AM, Trygve Reenskaug wrote:

• MVC is an idea, not a recipe. So what should I answer? It is very fuzzy.
  

Would it be valid to say that even a very different approach like an immediate mode GUI might still qualify as MVC as long as it focuses on the end user and facilitates the direct manipulation metaphor and separation of concerns? Or would that be confusing matters too much? I certainly think that many of the so-called variations such as Model-View-Presenter are still basically just MVC (or at least, they can be as long as the User, as in MVC-U, is not forgotten).

Almost all of them use the GOF Observer Pattern to link the model with the I/O. In my big MVC/DCI planning example, the Subject is the Model. It is implemented as a fuzzy kind of simulated database. Whenever this Model is changed, it sends an update-message to all its observers. In this case the Controller object is the only observer. The Controller knows all the Views and can do "the right thing" with its Views.

What I see more commonly these days is the Views observing the Model directly (via notification events emitted by the Model objects). The Controller still does other coordination between the Views and the Model, mostly related to user input events (although one can get carried away with that, as Cope just mentioned). Often the data-binding can be set up declaratively (e.g. in templates with a binding syntax). While not essential, I find this is more efficient for the programmer. But as you wisely pointed out, every project should be evaluated on its own terms, and the benefits and necessity of particular techniques vary.

Thanks,
Matt

[Egon Elbre]

On Sunday, 24 April 2016 21:11:15 UTC+3, Matthew Browne wrote:

Hi Trygve,
Thank you for your helpful explanation of some important context and background.

On 4/24/16 8:57 AM, Trygve Reenskaug wrote:

• MVC is an idea, not a recipe. So what should I answer? It is very fuzzy.
  

Would it be valid to say that even a very different approach like an immediate mode GUI might still qualify as MVC as long as it focuses on the end user and facilitates the direct manipulation metaphor and separation of concerns? Or would that be confusing matters too much?

It will depend on how you write your code.

IMGUIs are very direct in its purpose.

"I now want to a button with this information and if it's pressed do this."

This can have a lot of variations:

v1.1.

if(dobutton(counter)){

    counter.increment();

}

v1.2.

if(dobutton(counter)){

    counter++;

}

v1.3

if(dobutton(counter)){

    controller.countClick()

} 

v2.1.

dobutton(counter, func(){  counter.increment()  })

v2.2.

dobutton(counter, func(){  counter++  })

v2.3.

dobutton(counter, controller.countClick)

v3.

dobutton(&counter)

+ a ton of combinations with ID, position, styling, layouting...

--

The main thing about immediate mode, is that you don't have a "object graph" how the View is setup. The View isn't an object in IMGUI, it's just a function. Or alternatively, if you need a "new object graph" you rebuild it from scratch.

How you write your controller and model in that situation, can vary. It can be combined with the View; the click can invoke a function on the controller; or send an async message...

It supports very well the idea of building UI-s for direct manipulation. You can take a look at Unity Editor.

+ Egon

[James O Coplien]

Den 25/04/2016 kl. 09.08 skrev Egon Elbre <egon...@gmail.com>:

It will depend on how you write your code.

Again, I think that’s a nerd-centric perspective. (And, again, this mail has no picture.) Let’s bring the user into this. It is, after all, a user interface.

IMGUIs are very direct in its purpose.

"I now want to a button with this information and if it's pressed do this.”

A user never says, “I want to press a button.” A user says: “I want to achieve business goal or step X.” There are scores of ergonomic and design concerns that lead to a button. And there are scores of alternatives to buttons.

Speaking of separation of stuff ...

This can have a lot of variations:

v1.1.

if(dobutton(counter)){

    counter.increment();

}

Is this in the View, the Model, or the Controller? Given its access to counter I would guess it’s in the Model. Why does it assume that the interface element is a button? It could be a switch, or a latched slider, or any one of a host of other elements that have the behaviour of having two states and of sending a state change notification. Calling it a button here suggests accidental coupling between the actual interface, and the code.

The same with all the rest.

v1.2.

if(dobutton(counter)){

    counter++;

}

v1.3

if(dobutton(counter)){

    controller.countClick()

} 

v2.1.

dobutton(counter, func(){  counter.increment()  })

v2.2.

dobutton(counter, func(){  counter++  })

v2.3.

dobutton(counter, controller.countClick)

v3.

dobutton(&counter)

+ a ton of combinations with ID, position, styling, layouting…

The syntax won’t save you. You’ve lost the battle already by calling it a button. The rest is just syntactic saccharin.

[James O. Coplien]

Den 24/04/2016 kl. 20.11 skrev Matthew Browne <mbro...@gmail.com>:

But as you wisely pointed out, every project should be evaluated on its own terms, and the benefits and necessity of particular techniques vary.

What do you see as the evaluation criteria?

Sans such criteria, this sentence carries no information, at least for me.

[Egon Elbre]

On Monday, 25 April 2016 10:27:37 UTC+3, cope wrote:

Den 25/04/2016 kl. 09.08 skrev Egon Elbre <egon...@gmail.com>:

It will depend on how you write your code.

Again, I think that’s a nerd-centric perspective. (And, again, this mail has no picture.) Let’s bring the user into this. It is, after all, a user interface. 

IMGUIs are very direct in its purpose.

"I now want to a button with this information and if it's pressed do this.”

A user never says, “I want to press a button.” A user says: “I want to achieve business goal or step X.” There are scores of ergonomic and design concerns that lead to a button. And there are scores of alternatives to buttons.

A user never says, I want this button to trigger an event on the controller either. IMGUI-s don't solve this problem. I guess the more correct name for it would be "user interface elements library". It gives you a tool to create an user interface, but it does not guide what and how you should build it.

Speaking of separation of stuff ...

This can have a lot of variations:

v1.1.

if(dobutton(counter)){

    counter.increment();

}

Is this in the View, the Model, or the Controller? Given its access to counter I would guess it’s in the Model.

It depends. Theoretically it could be in any of them or it could be a separate thing.

* 1. Placing it inside the same namespace as the Model would mean that the interface is very coupled with the Model itself.

* 2. Placing it inside the same namespace as the Controller it would mean that you probably have many controllers (e.g. a grid of different controllers).

* 3. Placing it inside the same namespace as the View would detach it from the Model/Controller.

* 4. Making it a separate function would make it detached from all of them i.e. make it more reusable, this is how "button", "slider", "text" etc. are usually implemented.

Why does it assume that the interface element is a button? It could be a switch, or a latched slider, or any one of a host of other elements that have the behaviour of having two states and of sending a state change notification. Calling it a button here suggests accidental coupling between the actual interface, and the code.

You still have to define the element being used and the action somewhere. Is there a significant difference whether the binding is explicitly defined in code or in a data-file or wired by events?

[Egon Elbre]

On Monday, 25 April 2016 10:27:37 UTC+3, cope wrote:

Den 25/04/2016 kl. 09.08 skrev Egon Elbre <egon...@gmail.com>:

It will depend on how you write your code.

Again, I think that’s a nerd-centric perspective. (And, again, this mail has no picture.) Let’s bring the user into this. It is, after all, a user interface.

I probably should write the Prokon example to make it more obvious how the code will look.

[James O. Coplien]

Den 25/04/2016 kl. 10.30 skrev Egon Elbre <egon...@gmail.com>:

I probably should write the Prokon example to make it more obvious how the code will look.

… and how the interface will look?

[Egon Elbre]

The interface probably won't significantly change in the first iteration, unless I take shortcuts in implementing things.

[Trygve Reenskaug]

If yo ca say what is not MVC, then you have defined MVC. I've never attempted to do that.
On one level below, you could define MVC by a pattern language. My language is then a first shot at such an definition. I don't know if Cope would like this definition: An MVC architecture is an instance of the MVC pattern language. This implies thatwe have to find new names for any deviants.



check if an immediate mode GUI  is an instance of my pattern language. Very

[Matthew Browne]

I was simply agreeing with Trygve that what works well for one project might be unnecessary, or not work well, in another.

[Matthew Browne]

On 4/25/16 7:45 AM, Matthew Browne wrote:
> I was simply agreeing with Trygve that what works well for one project
> might be unnecessary, or not work well, in another.

...and confirming that MVC is an idea that encompasses more than one
implementation.

[Matthew Browne]

BTW Cope, as you may be aware, immediate mode vs. retained mode is very relevant to the discussion about time and state (as I just learned at this link Egon suggested), because immediate mode is basically stateless.

As an aside, I also just read (here) about how React (the JS UI library by Facebook) implements immediate mode using a virtual DOM that transparently updates the real (and retained mode) DOM. This might serve as inspiration for how to implement a less stateful UI on top of other existing UI libraries including AWT.

It may sound like I've totally "drunk the kool-aid" of immediate mode GUIs at this point but really I just find the idea interesting and am still exploring it (as Egon said, it's "not a silver bullet").

[Matthew Browne]

On 4/25/16 5:57 AM, Trygve Reenskaug wrote:

check if an immediate mode GUI  is an instance of my pattern language. Very

It looks like the last line of your email got cut off...was there supposed to be another sentence here?

[Egon Elbre]

On Monday, 25 April 2016 14:55:54 UTC+3, Matthew Browne wrote:

BTW Cope, as you may be aware, immediate mode vs. retained mode is very relevant to the discussion about time and state (as I just learned at this link Egon suggested), because immediate mode is basically stateless.

As an aside, I also just read (here) about how React (the JS UI library by Facebook) implements immediate mode using a virtual DOM that transparently updates the real (and retained mode) DOM. This might serve as inspiration for how to implement a less stateful UI on top of other existing UI libraries including AWT.

It may sound like I've totally "drunk the kool-aid" of immediate mode GUIs at this point but really I just find the idea interesting and am still exploring it (as Egon said, it's "not a silver bullet").

There's now an immediate mode example in trygve (https://raw.githubusercontent.com/jcoplien/trygve/master/examples/keypad.k).

+ Egon

[James O Coplien]

I don’t get it. What would be the difference if the example were not using immediate mode?

[Egon Elbre]

On Sunday, 1 May 2016 16:50:08 UTC+3, cope wrote:

I don’t get it. What would be the difference if the example were not using immediate mode?

For the end-user not much.

For the programmer, in the trivialized sense -- you don't have to manage the life-time of the controls.

You can compare how a button is implemented and used in:

* https://raw.githubusercontent.com/jcoplien/trygve/master/examples/keypad.k

* https://raw.githubusercontent.com/jcoplien/trygve/master/examples/borrow_library_panel5.k

From http://www.johno.se/book/imgui.html:

The user interface, from the point of view of the client application, most often looks like a collection of objects, typically one per "widget", which encapsulate state that needs to be frequently synchronized with that of the application. Such synchronization goes both ways; state moves from the application to the user interface in order for that state to become visible to the user, and state moves from the user interface back to the application when the user interacts with the interface in order to change the state of the application.

When the user interacts with the user interface, the client application must explicitly move state from the widgets back into application data structures. Sometimes, depending on the toolkit used, a level of automation is provided by the user interface toolkit for such "data exchange", but the synchronization itself (not to mention the duplicated state) is still a fact of life.

Additionally, the manner in which the application is notified of user interactions with the interface (which in turn signals a need for re-syncing of state) often takes the form of callbacks. This requires the application to implement "event handlers" for any low-level interaction that is of interest, often by subclassing some toolkit baseclass either manually or via various code generation tricks; in either case further complicating the life of the client application.

IMGUI does away with this type of state synchronization by requiring the application to explicitly pass all state required for visualization and interaction with any given "widget" in real-time. The user interface only retains the minimal amount of state required to facilitate the functionality required by each type of widget supported by the system.

With IMGUI, a conceptual shift occurs. Widgets are no longer objects at all, and can't really be said to "exist". They take instead the form of procedural method calls, and the user interface itself goes from being as stateful collection of objects to being a real time sequence of method calls.

+ Egon

[James O Coplien]

Den 01 May 2016 kl. 17:04 skrev Egon Elbre <egon...@gmail.com>:

Additionally, the manner in which the application is notified of user interactions with the interface (which in turn signals a need for re-syncing of state) often takes the form of callbacks. 

Hmm. Anything follows from a fallacy.

So if a momentary contact button should be illuminated when pressed, and it’s one of several options for sending an event to the model, then 1. the model has to know the difference between this and the others and 2. the model (or maybe the controller) has to know how to manage the colouring when the button is in a pressed *state*. Am I right?

[Raoul Duke]

Yes!

> We need UX for application (easy to use), for code (easy to understand), UX for library (easy to  use), UX for domain services (easy to integrate)....

[Egon Elbre]

On Sunday, 1 May 2016 19:05:08 UTC+3, cope wrote:

Den 01 May 2016 kl. 17:04 skrev Egon Elbre <egon...@gmail.com>:

Additionally, the manner in which the application is notified of user interactions with the interface (which in turn signals a need for re-syncing of state) often takes the form of callbacks. 

Hmm. Anything follows from a fallacy.

Which part was the fallacy?

 

So if a momentary contact button should be illuminated when pressed, and it’s one of several options for sending an event to the model, then 1. the model has to know the difference between this and the others

Not quite following this part. Do you mean a physical button?

There are several options for setting this up:

(A) a controller captures the state change and dispatches the appropriate message to the model

(B) it is used as part of the input state

Either way when the View updates then the color is calculated or fetched from the model or view.

and 2. the model (or maybe the controller) has to know how to manage the colouring when the button is in a pressed *state*. Am I right?

The state or logic for coloring can be in the View/Controller or Model, depending whether it's part of the Model.

[James O. Coplien]

Just had a seance….

On 24 Apr 2016, at 14.57, Trygve Reenskaug <try...@ifi.uio.no> wrote:

I never know what to answer when I get questions about MVC.

• MVC is more than a class library because it can give rise to several, different class libraries.
• MVC is more than a role model, because several, different role models could describe MVC. I've had MVC implementations where M, V, and C where all played by the same object.
  
• MVC is more than a pattern language because it could give rise to several, different languages.
• MVC is an idea, not a recipe. So what should I answer? It is very fuzzy.
  

I think I once wrote a long mail about the MVC background. There's no way I could find it now. I started the Prokon project around 1980.  Its goal was to support a business organization with  distributed authority and responsibility. Each manager should be given their personal  (virtual) computer with programs they could understand and possibly write. The first example was a distributed planning system where each manager could shape  their planning program to fit their particular needs. The overall plan was distributed among these computers and integrated through communication between them. (The Prokon project stopped abruptly when our sponsor's main customer went bankrupt.)  At PARC, I concentrated on the part-problem of a manger working with a plan that could potentially consist of several hundred activities. The novel direct manipulation interfaces that were possible through the Alto computer and Smalltalk programming environment made for a fun project. 

The current thoughts in Alan Kay's group was that objects should be visible and tangible.  I faced the problem that there an activity should be made visible in many different ways. There was also the problem of making structures of related activities visible on the screen. I had always been a fan of separation of concerns. In particular, I advocated that there should be a separation between the UI part of the program and the part with the actual subject matter (a Plan, a Ledger, an Inventory...) With this separation, programs could be run by other programs as well as by humans. The first MVC implementation was a concrete program design I made at at PARC. It had an elaborate separation of concerns. People got exited about it, possibly because they saw it was more fundamental than I realized at the time.

I have written many programs through the years that are based on MVC. They no longer exist and can't be used as illustrations. Almost all of them use the GOF Observer Pattern to link the model with the I/O. In my big MVC/DCI planning example, the Subject is the Model. It is implemented as a fuzzy kind of simulated database. Whenever this Model is changed, it sends an update-message to all its observers. In this case the Controller object is the only observer. The Controller knows all the Views and can do "the right thing" with its Views. The separation of concerns is pretty deep: The Model doesn't know the I/O objects apart from its list of observers and only the Controller knows the Model.(In this example, the I/O and Model parts are further decomposed separately according to the DCI paradigm.)

[James Coplien]

On 23 Apr 2016, at 12.54, Matthew Browne <mbro...@gmail.com> wrote:

I obviously still have a lot to learn about patterns, but I don't think this is true.

Trygve certainly viewed it that way; look at his pattern language.

[Matthew Browne]

Thanks for finding that.

To view this discussion visit https://groups.google.com/d/msgid/object-composition/E1221BC7-AA52-46FA-8012-271879AAFC6D%40scrumplop.org.

[Matthew Browne]

Hi Cope,
I think you're saying that MVC is a design pattern, is that right?

Here's my original quote from back in 2016:

On 4/23/16 6:19 AM, Hai Quang Kim wrote:

The MVC is not a design pattern, it is a solution for an organization.

I obviously still have a lot to learn about patterns, but I don't think this is true. I get what you're saying - Trygve's original MVC solution was very much focused on the needs of a particular organization - but I think all patterns start out as a solution for a specific problem, and then people discover that the same approach can be successfully used elsewhere, and over time it becomes a pattern.

—

Matt Browne (he/him)

--
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 view this discussion visit https://groups.google.com/d/msgid/object-composition/9BE68528-343D-45E1-8B71-59A1E98175E6%40yahoo.com.

[James Coplien]

On 21 Mar 2026, at 22.38, Matthew Browne <mbro...@gmail.com> wrote:

I think you're saying that MVC is a design pattern, is that right?

No, it’s a pattern language, in most contexts. I guess the Whole of any pattern language could be reflected in a single higher-order pattern, but it’s not common, kind of defeats the purpose, and doesn’t reflect the granularity of concerns that usually arise around its use.

[Matthew Browne]

Ah I see, I didn't quite get the distinction before. Yes, I think it's better to think of MVC as a pattern language - I thought the draft pattern language Trygve spearheaded was great. I like how it starts with basic patterns and doesn't even require the use of the Observer pattern for simple cases, and offers flexibility in the patterns you choose instead of prescribing just one strict way of doing it.

--

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 view this discussion visit https://groups.google.com/d/msgid/object-composition/DF6C9A62-8A4D-4F4F-B468-13AA13B0D04F%40yahoo.com.