On 17 November 2014 11:38, Henrik Johansen <henrik.s.johansen@veloxit.no> wrote:

> On 15 Nov 2014, at 10:41 , stepharo <stepharo@free.fr> wrote:
>
> initializePresenter
>�� "Used to specify the subwidgets, and/or to bind them together"
>�� "By default, do not do anything"
>
>�� extentHolder whenChangedDo: [:ex |
>�� self widget ifNotNil: [:widget |
>�� (widget respondsTo: #extent:)
>�� ifTrue: [ widget extent: ex ]]].
>
>
> may be by design the ifNotNil should not be needed and the respondsTo too....
>
> pffff.
>

I don't get it, doesn't the presenter already have an initialize: method that gets passed in its model?

So a more "proper" thing to do is
PresenterClassesThatCaresAboutExtent >> initializeFromModel: myModel
�� myModel extentHolder when: ChangedValue do: [:ann | self extent: ann newValue]

The controller and presenter(or view) are always in 1:1 correspondence, not

one to many.

The idea that you can easily swap out presenter, leaving controller intact is IMO wrong.

You either drop both of them and create another pair, if you want,

but you never drop only one of them because, by nature, they form a very strong relationship.. which goal is: properly represent the domain object in GUI.

For domain object(s), however there's no 1:1 correspondence between domain object its views.. single domain object can have multiple different views. But that in fact means it can have multiple pairs of controller+presenters at once.

My point that there's no need for things like 'windowChanged' , where window role is a view in MVC (or MVP) models, to be handled by controller, since it is never changes for single pair of controller and presenter during their lifetime, once initialized and set up.

Cheers,
Henry

Best regards,
Igor Stasenko.