On 20 Feb 2015, at 12:23 , Nicolai Hess <nicolaihess@web.de> wrote:



2015-02-19 23:24 GMT+01:00 Johan Fabry <jfabry@dcc.uchile.cl>:

The problem is that people are confused by the term Model, so they will also be confused by Logic. I want to remove the confusion and make clear that it is a user interface (and that it is composable by default) -> ComposableUI.

It could also be ComposableUserInterface but we do not win anything by that name, as UI is a standard acronym + we would have to type more when subclassing it. So I prefer ComposableUI.

But this *is* a model, not a UI. Yes a model for the UI, but still, the real UI-View is what comes through the Spec interpreter.
"UI" sounds like "the whole user interface", but Specs ComposableModels are meant as "building blocks".


UI-Model -> WidgetAdapter -> Widget/View.

I would prefer (in this order):
1. ComposableModel (because this is the current name)
2. ComposableWidgetModel (widget: a brick or part of an UI)
3. ComposableUIModel
4. ComposableUI

I am not fully against 4., because it is the goal of spec to build reuseable UIs.
For example for a Spec based "ListSelectionDialog" we can reuse the whole component, not only the model, not only the view, but the
whole component with interaction between the list and other controls.
But I would prefer ComposableWidgetModel, because a "Widget" (button/textfield/list) is the smallest unit of a user interface representable with Spec.

If the goal is avoiding confusion to data model classes, why not just use Spec in place of Model?
It reflects the framework name, and is fairly descriptive in that the classes are neither the actual widgets, nor the models that hold data, but a specification of how they are composed and wired together.

Cheers,
Henry