Hi rob

we are discussing in Peter and reading your solution.
Now about your example, I think that the

Presenter >> subject: aDomainObject
     subjectHolder := aDomainObject asValueHolder

We should not have countHolder in the domain object. In the domain object
we should only have the domain and no value holder. Now to access a
part of a domain
object to refresh/change it without changing the whole, we should
have something similar to AspectAdaptor in VW.

What do you think?

Stef


On Sat, Sep 30, 2017 at 9:21 PM, Stephane Ducasse
<stepharo.s...@gmail.com> wrote:
> Hi rob
>
> I wrote this missing chapter and I think that it exhibits the changes
> you wanted to introduce.
> So let me know.
>
> Stef
>
>
> On Sat, Sep 30, 2017 at 9:13 AM, Stephane Ducasse
> <stepharo.s...@gmail.com> wrote:
>> Hi rob
>>
>> where can I find your code because I'm really thinking that something
>> is missing in Spec.
>> I'm writing a little editor for a gameItem and I should go through and
>> I would like to use it
>> as an example of what I do not like.
>> In fact I would like to have all the models to work on aspect of the
>> domain model.
>> May be this is avaialbale in spec but I forgot and I forgot to
>> document it in the book.
>>
>> Stef
>>
>>
>> On Tue, Sep 5, 2017 at 8:49 PM, Rob Rothwell <r.j.rothw...@gmail.com> wrote:
>>> Hello,
>>>
>>> I was wondering what more experienced users than myself thought of the idea
>>> of an explicit Spec "connection point" to a domain model object similar to
>>> Dolphin's "showOn:" method, like:
>>>
>>> CounterApp showOn: counter.
>>>
>>> This would perhaps trigger something like Dolphin's Presenter>>model:
>>> message (although I've always found the use of "model" confusing when there
>>> are so many "models" involved.) after the widgets had been created:
>>>
>>> ComposableModel>>initializeBindings: anObject
>>>
>>> In many cases, if your domain model uses ValueHolders as well (like Spec
>>> does), making a connection could just mean replacing the Spec ValueHolder
>>> with your domain ValueHolder so changes to the domain model would
>>> automatically propagate to the UI presentation without providing explicit
>>> code in ComposableModel>>initializePresenter.
>>>
>>> However, since I am still trying to understand and learn Spec, it's quite
>>> possible I am missing some key point and there are reasons not to explore
>>> this line of thinking!
>>>
>>> Thank you,
>>>
>>> Rob
>>>

Reply via email to