Newbie: How to? Pluggable ValueModels

The MVP framework in Dolphin is very impressive. I have been mostly
fiddling with subclasses of the Dialog presenter and the AspectBuffer
ValueAspectAdaptor classes. What strikes me is that this works fine as
long as the model is implemented in a get/set way, but breaks as long
as the model isn't implemented that way.

What is the usual way to work around this? To have a kind of
application model class that implements the get/set interface that the
AspectBuffer protocol requires and delegates to the actual model, or
is there some way of having pluggable ValueModels with blocks for
value and value: onto different parts of the model?
--

Vennlig hilsen

Syver Enstad

Syver Enstad <[hidden email]> writes:

As nobody seems to be interested in this, I try to be a bit more
concrete and describe the model method of a hypothetical presenter.


Model subclass: #MyModel1

methods:
 isOn: aBoolean
 isOn


Dialog subclass: #MyDialog



MyPresenter>>model: aModel
    super model: aModel.
    (self presenterName: 'on') model: (self model aspectValue: #isOn).

This works fine when the model has this type of get/set interface

But if aModel was of the following class:
Model subclass: #MyModel2

methods:
  setOn
  setOff
  isOn

It would be cool to do something like this.

MyPresenter>>model: aModel
   super model: aModel.
   (self presenterName: 'on') model:
        (self model
             pluggableGetBlock: [:subject | subject isOn]
             setBlock: [:subject :value | value
                ifTrue: [subject setOn]
                ifFalse: [subject setOff]).


Where pluggableGetBlock: setBlock: was implemented in AspectBuffer (or
a subclass) so that the copying needed by the Dialog presenter was
handled.

I just wonder if this is the way to go, or if handling this case is
already handled in another way within the dolphin image?

--

Vennlig hilsen

Syver Enstad

Syver,

> > The MVP framework in Dolphin is very impressive. I have been mostly
> > fiddling with subclasses of the Dialog presenter and the AspectBuffer
> > ValueAspectAdaptor classes. What strikes me is that this works fine as
> > long as the model is implemented in a get/set way, but breaks as long
> > as the model isn't implemented that way.
>
> As nobody seems to be interested in this, I try to be a bit more
> concrete and describe the model method of a hypothetical presenter.

Well, it's not so much not interested, as stumped :)   MHO on the subject is
that anything that's more than "skin deep" will cause trouble with Dialog's
buffering algorithm.  I finally created a NonBufferedDialog subclass of
dialog that does not buffer.  Of course, I have to make a copy of the model
(it follows that #copy has to work correctly) and deal with any cancel
issues on my own.  One of the first dialogs to force this issue is so
complicated (or maybe powerful is a better word<g>) that I took the Cancel
button off of it entirely - users were shooting themselves in the foot with
it, because they'd a lot of work and then cancel it at the end.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Syver,

> Where pluggableGetBlock: setBlock: was implemented in AspectBuffer (or
> a subclass) so that the copying needed by the Dialog presenter was
> handled.
>
> I just wonder if this is the way to go, or if handling this case is
> already handled in another way within the dolphin image?

It seems to be a over complicated way of going about it. In the situation
you describe I would either

- Add a accesssor to the model class and then implement #setOn and #setOff
using the setter. This would obviously also provide the correct interface
for the dialog. This would seem the most obvious, and best way but ...

- If, for some reason, you were unable to make the model comply with the
value/value: interface then I would do the buffering myself using the
default model in the presenter.  The model would be unchanged and you would
have

MyPresenter>>onViewOpened
    [blah]
    (self presenterNamed: 'on') value: self model isOn

MyPresenter>>ok  (or override #apply maybe)
    [blah]
    (self presenterNamed: 'on') value
        ifTrue: [self model setOn]
        ifFalse: [self model setOff]

Regards
    Ian

"Ian Bartholomew" <[hidden email]> writes:
  Yes, I know it's the obvious, I just looked at it from the purist
viewpoint, because I read that some of the point with MVP was that GUI
issues didn't have to creep into the model. And adding all sorts of
getters and setters to the model do complicate the model making it
more difficult to understand.


Thanks, I've saved this and will look into it. I think I'd prefer
doing it in the presenter.

--

Vennlig hilsen

Syver Enstad