> On 20 Feb 2015, at 12:23 , Nicolai Hess <[email protected]> wrote: > > > > 2015-02-19 23:24 GMT+01:00 Johan Fabry <[email protected] > <mailto:[email protected]>>: > > 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
