AspectBuffer delegation issue

I am suprised that in AspectBuffer #apply the code is as follows:

apply
        "Apply the aspects held by the receiver in the model copy back to the
        original model"

        aspects do: [:each |
                self subject perform: each putSelector with: each value ]


I would expect the buffer to delegate the perform to each of the aspects
- thus you could create a ReadOnly aspect that didn't do an update/apply -

eg.

apply
        "Apply the aspects held by the receiver in the model copy back to the
        original model"

        aspects do: [:each | each apply ]

The self subject perform... would be moved to ValueModel (or maybe even higher
in the hierarchy)?

This request is driven from Ted Bracht's book - I'm working my way through
the examples and finding that the whole topic of hooking up presenters much
more complicated than it should be - the way that he describes handling the
age of driver should be a trivial operation of hooking up a read only presenter
- I don't get why it requires a differnt way of thinking and you hook up
your own #when:send: handlers.  I also don't understand why when the driver
dialog is opened you have to prod the age presenter - surely when it draws
the first time it realises it doesn't have a value and should read one?

Tim

Tim,

> I am suprised that in AspectBuffer #apply the code is [...]
> I would expect the buffer to delegate the perform to each of the aspects
> - thus you could create a ReadOnly aspect that didn't do an update/apply -

It does seem a little clumsy.

BTW, I think you can create a read-only aspect (without extending the base
system) by setting its #comparisonPolicy to (SearchPolicy always).  I admit I
haven't tested it...

Of course, that won't work with AspectBuffer>>apply :-(


> This request is driven from Ted Bracht's book - I'm working my way through
> the examples and finding that the whole topic of hooking up presenters
> much more complicated than it should be - the way that he describes
> handling the age of driver should be a trivial operation of hooking up a
> read only presenter - I don't get why it requires a differnt way of
> thinking and you hook up
> your own #when:send: handlers.

I think that passage of Ted book is driven by two things -- the fact that he's
using dialogs, and a desire to illustrate another way of hooking things up.

In my opinion, dialogs (except trivial ones) are a poor UI idiom, and it would
seem that OA agree, since they make almost as little use of them as I do.  In
any event, I don't think the dialog framework in Dolphin is intended to be
particularly sophisticated, nor to cover all the possible cases.  For instance,
there is no notion of read-only aspects.   It might be unfair to characterise
it as a bit of a hack intended only for simple applications, but that's how I
see it.

If we ignore dialogs, then the system works better.  There is the ability to
tell an aspect adaptor that it is reflecting a value which can change (with
notification) independently in the model.  For instance (added to Ted's code in
#model:)

     agePresenter model: ((self model aspectValue: #age)
                          aspectTriggers: #dateOfBirthChanged);
                          yourself.

And there is no need to set explicit handlers for the model's change events nor
use Presenter>>#valueChanged.  Unfortunately, and only because we are using
dialogs, that will attempt to write back the #age into the model on <OK>.  IMO,
the best solution is not to use dialogs.  If you /must/ use dialogs then you
could add a dummy #age: method to Driver or fix/extend the dialog framework...

Incidentally, Ted's book is wrong to suggest (earlier in that chapter) that it
enough for the Driver to trigger #nameChanged -- that does not cause the name
field to update automatically.  You also need to use the #aspectTriggers:
message to arrange for the namePresenter to "see" implicit changes to the
model's #name.


> I also don't understand why when the
> driver dialog is opened you have to prod the age presenter - surely when
> it draws
> the first time it realises it doesn't have a value and should read one?

Do you mean that you have to use an override of #onViewOpened (or
#onViewAvailable) ?  If so, then I don't know what's going wrong; from the
look of Ted's code it /should/ work without that.

    -- chris