Part Three To minimize the quantity of ad-libbing, the text is translated very closely in meaning, as a result of which the translation acquires “chopped” features. Those who decide to read should read carefully, for what they read can harm the inner sense of aesthetics.

The previous part is here . The original article is here .

VisualWorks Application Model

As I said above, the MVC pattern in the Smalltalk 80 language was very successful and had a set of excellent features and some flaws. In the course of the Smalltalk development in the 80s and 90s, all this resulted in significant changes in the classical MVC model. To tell the truth, what defines its name from MVC is the separation of the view from the controller.
')
There are aspects that obviously worked in MVC - this is a separated presentation ( Separated Presentation ) and synchronization through a browser ( Observer Syncronization ). These aspects for many people were a key element of MVC and continued their development along with the Smalltalk platform.

Smalltalk also went along several different branches of development. Several Smalltalk platforms appeared, with a single language definition, but with different libraries. Some of them began to use "native" controls for the operating system in the style described in "Forms and Elements".

Smalltalk was developed by Xerox Parc, after which it singled out sales and development of the platform into a new firm, ParcPlace. The ParcPlace Smalltalk system was renamed VisualWorks and made it cross-platform. Long before the advent of Java, you could take a program written in Smalltalk in the Windows operating system and immediately launch it in the Solaris OS. To do this, VisualWorks did not use native controls and kept the GUI completely internally.

I ended up discussing MVC by highlighting several problem areas — in particular, how to work with presentation logic and view state. VisualWorks solved these problems by creating a new special design, the so-called. Application Model (Application Model) - a design that is close in meaning to the Presentation Model . The idea of ​​creating something like ( Presentation Model ) was not an innovation - even in Smalltalk 80, the code browser was very similar to it, but VisualWorks explicitly selected the application model in its framework.

The key to this idea is the transformation of properties into objects (property objects). Consider an example - a Person object with two properties - the name Name and the address of Adress. These properties can be class fields or something else. In Java, to access the properties of an object, we write temp = aPerson.getName() and aPerson.setName("martin") . In C #, temp = aPerson.name and aPerson.name = "martin" .

The property object returns a wrapper object with the current value of the property. Thus, if in VisualWorks we request the name Name from Person, we will get the Name wrapper object. And the name Name itself is obtained through a direct request to the value of the wrapper object. You can provide access to the Name name like this: temp = aPerson name value and aPerson name value: 'martin'

This approach makes it a little easier to display data between controls and a model. You just need to tell the element what message it needs to send to the corresponding property. Thus, the element will know how to access the property value through the value and value: code. In VisualWorks, property objects also allow you to customize the browser through a message like onChangeSend: aMessage to: anObserver.

By the way, in VisualWorks there is no object called Property Object (Property Object). Instead, there are several other classes that support the value / value: / onChangeSend: protocol. The simplest of these is the ValueHolder class. This class simply contains the value of the property. A more complex and relevant class for this discussion is AspectAdaptor. It allows a property object to wrap a property of another (!) Object. Thus, it becomes possible to make the PersonUI class and define in it an object-property for the Person object. The code will be something like this:

adaptor := AspectAdaptor subject: person
adaptor forAspect: #name
adaptor onChangeSend: #redisplay to: self


Let's see how the application model will fall into our current example:



Figure 9: Class diagram for the VisualWorks application model in our example

The main difference between the application model and the classical MVC is that we now have an intermediate class (application model) between the domain model and the control. Controls are no longer accessible to domain objects directly - their model is now the application model. They are also divided into views and controllers, but as long as you do not create new controls, this partition does not play a big role.

Aspect assignment for controls occurs as usual in the UI editor. An aspect corresponds to an application model method that returns a property object.



Figure 10: A sequence diagram showing how updating the current value updates the deviation text

Figure 10 shows how data refresh works. When I change the value in the text field, this field updates the value in the property object belonging to the application model. Then the value in the underlying domain object is updated.

Then comes the browser case. We need to configure the system so that the update of the current property causes the object to "stop" to tell everyone that it has changed. We do this through a special call in determining the current value - in particular, it is needed in order to inform you that the deviation aspect has changed. Aspect adapter (aspect adapter) is very easy to configure to monitor the object "measurement". When needed, he catches the update message and forwards it to the text field. After that, using the same aspect adapter, the text field gets a new value.

Using the application model and property objects helps us to cope with data updates with little blood. They also support fine-grained synchronization (and I don’t think this is good).

Application models allow you to separate UI-specific behavior and state from domain logic. Earlier, I mentioned one problem, about where to properly store the value for the currently selected object from the list. It can be solved by introducing a special type of aspect adapter, which will wrap the list of domain objects, as well as store the current selected one.

The limitation of this approach is that with more complex behavior, you will have to create special controls and property objects. For example, in the examples above, the assignment of a color to a deviation text field is not affected. Using the separation of application and domain models, you can enter the correct behavior, but to create connections between aspect adapters and controls you will still have to write several new classes. This is often too complex, so we can relax the requirements and allow the application model to access the controls directly. See figure 11 .



Figure 11. The application model updates the text field color by directly accessing it.

Direct access to controls is not exactly what was meant when describing a presentation model ( Presentation Model ). That is why the application model is not a presentation model ( Presentation Model ). The need to access the controls directly is perceived by many as a small “dirty trick”, which allowed the development of the Model-View-Controller approach.

Let's sum up the presentation model.

• The presentation model followed MVC through the development of a split presentation ( Separated Presentation ) and synchronization through a browser ( Observer Syncronization ).
• The representation model is an intermediate class where the presentation logic and the presentation state are described. The application model is a partial development of the Presentation Model .
• Controls no longer view domain objects. Instead, they review the application model.
• Extensive use of property objects helps the developer to connect different layers of the application and maintain synchronization through browsers.
• The application model has direct access to controls. This behavior is not the default behavior, but is actively used in complex scenarios.

The next part is here .