MVP Nightschool revisited

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

MVP Nightschool revisited

Fernando Rodríguez
Hi,

In the last stage (4) 2 textboxes are added to the view to show the
latest returned and latest checked out books.

Ian uses 2 'manual events' called #lastCheckOutChanged and
#lastReturnChanged.

I tried to remove these and let the MVP framework take care of the
notification. So, instead of keeping the title of the latest books in
Strings, I kept them in a String inside a ValueHolder. Hopefully, the
ValueHolder would notify (via #valueChanged) the presenter.

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.

How can I fix this?

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...)


Reply | Threaded
Open this post in threaded view
|

Re: MVP Nightschool revisited

Ian Bartholomew-19
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.