>From design point of view I think we should remove adapters at all. They
bring parallel hierarchy which is always bad.
In fact they are not adapters. They are factories which creates backend
views (morphs). And now there are completely no logic behind them: every
adapter just passes state received from model to view instance.
I think full hierarchy of adapters can be easily substituted by single
backend factory class like MorphicViewFactory. Every model will ask it to
create concrete view instance. Actually I have another idea: we do not need
this factory at all.
Now Spec allows very restricted relationship between model and view. We can
only have single kind of view per model (MorphicAdapterBindings defines
this relation). There is no way to use different kind of views for same
model in single application.
Maybe current design tried to address this issue. But it not works. And
interesting that all Spec based tools do not require such kind of
flexibility which means that it is not really an issue.
Now you can imaging that if we always use same view class for same model
class then we can directly ask model to instantiate view. Message can be
backend specific like createMorphicView: and we need hierarchy of backends
here which will choose appropriate message.
P.S. Every time I read word model in Spec I feel something bad. It should
be named to presenter. But it is quite difficult due to compatibility. And
I am not sure that others agree with this.
2017-04-28 0:04 GMT+02:00 Peter Uhnak <i.uh...@gmail.com>:
> Hi Rob,
>
> I guess the best resource at the moment is to just look at existing
> adapters.
>
> But here are some thoughts to get you started:
>
> (Spec) ComposableModel has as its widget (Spec) Adapter
> Adapter has as its widget the actual visual component, which currently
> means Morphic.
>
>
> The simplest example: LabelModel
>
> 1. model to adapter
>
> LabelModel is adapted by MorphicLabelAdapter:
>
> you can see on the class side in method `defaultSpec`.
> There is only `LabelAdapter` there because there is some extra mapping for
> some classes, but you can specify directly the class of the Adapter, so the
> following would work just as well:
>
> LabelModel class>>defaultSpec
> <spec>
>
> ^ #(MorphicLabelAdapter
> adapt: #(model))
>
>
> LabelModel -> LabelAdapter direct event propagation (pushing changes)
>
> in Model world you can call changed:with: to execute code on the Adapter,
> e.g.
>
> self changed: #emphasis: with: {emphasis}
>
> which in turn will call the #emphasis: method on the LabelAdapter.
>
> LabelModel -> LabelAdapter events (pulling changes)
>
> preferred alternative is to do the opposite; properties of models are
> often held in ValueHolders, which can be observed on ValueChange, so the
> Adapter can register to event change and react on itself;
>
> you can see this best in MorphicTabAdapter (but you will see that
> TabAdapter looks a bit different from the rest, because I was experimenting
> with cleaning up Adapters...)
>
> 2. adapter to morphic
>
> Every adapter implements #buildWidget method that returns a Morphic Object.
> Typically the adapter registers itself as the model of the adapter (so
> adapter's model is Spec, and Morphic's model is the adapter). This depends
> a lot on the API of morphic. (in TabAdapter I'm overriding adapt: so
> there's no buildWidget, and it is in #buildWidgetWith:).
>
> It is all kinds of messy, but if you have other widgets then it will be a
> good test how well Spec can handle it... or rather we'll see how it can be
> improved...
>
> Peter
>
>
>
> On Thu, Apr 27, 2017 at 05:10:39PM -0400, Rob Rothwell wrote:
> > Hello,
> >
> > I have recently been lucky enough to get the Cocoa portion of Mars
> working
> > on Pharo 5.0. While there are some issues, it has a wonderful set of
> > examples that allowed me create new Cocoa classes and delegate methods
> and
> > see a straightforward path to learning how to use Coco widgets from
> Pharo.
> >
> > I'd like to do that by creating appropriate Spec adapters, but
> > unfortunately the new Spec booklet wasn't designed for that!
> >
> > Can anyone give me any insight into creating (and using) a new Spec
> > adapter? Maybe just some high level steps to help me orient my
> > investigation into how Spec works?
> >
> > Thank you,
> >
> > Rob
>
>
