[Seaside] Rendering fontawesome tag..

Fri Feb 22 07:16:12 UTC 2019

Hi Esteban,

For desktop:
- It uses MVC for building desktop apps, which is way cumbersome for
my taste, compared with Dolphin's MVP or Pharo's Spec (also MVP
AFAIU), VW's MVC has a lot of accidental complexity.

reading that i think you try to write a GUI in VisualWorks programmatically, just like you’d do in Seaside. If you do that the MVC in VisualWorks indeed is complicated. And because of that, no-one really does that. The complexity comes from knowing how to compose the widgets in Wrappers and how to connect and configure the controller. These are tasks that the UIBuilder and UILookPolicy perform based on UISpec objects (you add the spec to the builder and have it do the work). This task is done automatically when you open an ApplicationModel, where it reads the UISpec from the #windowSpec method. This method is configured in the UIPainter.

Until here none of the stuff is something a developer typically touches (not even if create your own widget).
What a developer typically does is configure the UI using UIPainter and here another abstraction kicks in: ValueModels.

The M in MVC in VisualWorks in the Model of the View and the Controller and it’s typically not specific to a widget. The model of a text-widget might seem to be a string, but it’s a ValueModel, just like for a Checkbox, it’s not a boolean but again a ValueModel.

The idea here is to introduce a uniform model to be used by all the widgets. ValueModels react to #value and #value:. They also solve the loose-coupling problem that the model shouldn’t know about the view(s) that display the model. In addition the views can still be informed by their model when the model changes (they use the so called „Dependency" mechanism, which is a very lightweight observer pattern).

The result of this Model architecture is that in your ApplicationModel, where you describe your UI, you only need to provide the ValueModels and don’t need to care about the Views and Controllers anymore. You want to change the value that’s shown by a widget, you update the ValueModel’s value and the view automatically redraws itself. Same goes the other way around, if the controller modifies the value, it updates the ValueModel and you can access the new value from the ApplicationModel. You can even registers to the dependency mechanism to be informed as soon as a value changes.

ValueModel is a class hierarchy and the most basic subclass is ValueHolder (the default, if you create a simple UI). The ValueHolder implements the #value/#value: contract simply by having an instance variable and providing accessors to it. There’s one addition: in #value: it triggers the dependency mechanism by calling „self changed: #value“.

More sophisticated ValueModels are AspectAdaptors, which allow you to quickly connect a widget to an attribute of a domain model. If you have a Person with a #name attribute, you can create an AspectAdaptor that will send #name when it is asked for its #value and it’ll send #name: when #value: is called. In addition, it supports the same dependency mechanism from its domain model, so if the the Person’s #name is changed, the Person can say: „self changed: #name“ and the AspectAdaptor will notice that its value has changed and it’ll propagate this information via „self changed:#value“ to be picked up by the views.

There are also subclasses of ValueModel that cover the following problems:
- provide a read-only value model for derived attributes that update automatically when the underlying value changes.
- connect the contents of a widget with the attribute of an object that’s selected in a list of objects. That allows you to update a bunch of widgets without writing a single line of code, you just configure their connection and you’re done.
- implement accept/cancel by buffering the user provided input before it is sent back to the domain model. That way you don’t need to keep a copy of your domain model around just to not modify the domain model instantly when the user changes a value.

The best part is: you can configure most of that directly from the UIPainter and don’t need to manually create the correct ValueModel in code.

> VW has been a very progressive environment and I remember Cincom has been ahead of the pack in innovations in the mid 2000‘s ...

Yeap, it was. Now I think it isn't.

On macOS the Cocoa bindings get very close to what you can achieve with ValueModels but it’s not available on iOS. I’ve not seen any other system yet where this kind of abstraction was introduced so you always have to keep your widgets around and tell them when a value was changed. At least on macOS / iOS this is not uniform so you have to know what object you put into which widget. You could use KVO on macOS / iOS but that’s quite messy to setup.

When we created seaBreeze we didn’t initially consider ValueModels and every time a value changed we needed to tell the UI to update the appropriate parts of the UI. Once we added support for ValueModels the development became much easier. Now we change a value and the UI picks that information automatically, just like in VisualWorks.

Other than that VisualWorks started to improve on the VC part of MVC in recent releases, too. The new ViewEventControllers can be composed instead of having to be subclassed, which makes development of new widgets a whole lot easier, as well as easing the pain when extending the behaviour of existing widgets.

The biggest problem with the VisualWorks UI stuff is that if you don’t know how the ideas are, it appears unreasonably complex and impossible to use. Reading the manual would help, but who does that? Only reading up on certain widgets doesn’t really help understand the underlying concept.

Kind Regards

Karsten
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/seaside/attachments/20190222/5c3cc427/attachment.html>