|
Fernando,
> However, when I check out a book or return it, the view is not
> updated. I guess it's because the TextPresenter didn't subscribe the
> #valueChanged event of the ValueHolder.
Did you share the TextPresenter's ValueHolder with the Library? Through
something like
LibraryShell>>model: aLibrary
[...]
aLibrary lastReturned: self lastReturnedPresenter model
I can't try it out though as I haven't got the code.
> Anyway, is this sort of thing (creating the least number of 'extra' or
> 'manual' events) a good idea? It does reduce the code I have to
> write, but end up having to use classes whose meaning isn't always
> very obvious (ValueHolder instead of String, ListModel instead of
> SortedCollection, etc...)
Personally I don't bother. A few extra, explicitly named. events doesn't
slow anything down much and, if anything, makes it easier to understand the
interaction between Model and Presenter. I also found that you tend to end
up with a mix, some variables in the Model being held as "normal" classes
and some as "wrapper" classes. You end up with extra accessor methods for
each wrapped variable, something like ....
myModel>>myVariableWrapper: aValueHolder
myModel>>myVariableWrapper
myModel>>myVariable: aStringOrWhatever
myModel>>myVariable
some of which talk to the ValueHolder and some to the value it contains. It
can get confusing.
I don't think there can be any hard rules about when and where to create
your own events. It's one of those areas where you do what "feels" right
and, usually, "is easiest"
--
Ian
Use the Reply-To address to contact me.
Mail sent to the From address is ignored.
|