CardPresenter Schematic plumbing

Hi,

I have been playing around card presenter. Iwanted to catch the moment when
current card is changed. My first try was to hook-up to CompositePresenter
in hope it will pass-along currentCardChanged, but it did not work.

After some poking around the image and Bill's DSDN, where I saw you were
hooking-up directly to the view, not to the presenter. Is this "the way to
do it" r just a short-cut?

If this is the way to do it, are there other typical cases when I am
supposed to hook-up directly to the view insted of the presenter?

Davorin Rusevljan

"Davorin Rusevljan" <[hidden email]> wrote in message
news:99f0en$ds5g$[hidden email]...

> I have been playing around card presenter. Iwanted to catch the moment
when
> current card is changed. My first try was to hook-up to CompositePresenter
> in hope it will pass-along currentCardChanged, but it did not work.

Here is what I am doing currently.  BigPresenter has an instance variable
'cardPresenter' and in the view composer I name the corresponding widget
'cards'.  I guess you are right, that I'm not really using the presenter
much.  But in case it helps, here it is.

BigPresenter>>createComponents
     super createComponents.
     cardPresenter := self add: CompositePresenter new name: 'cards'.

then I attach to the card changed and changing events this way:

BigPresenter>>createSchematicWiring
     super createSchematicWiring.
     cardPresenter view
          when: #currentCardChanging: send: #onCardChanging: to: self;
          when: #currentCardChanged send: #onCardChanged to: self.

Then in the #onCardChanging: (for the card being left) and #onCardChanged
(for the new card) methods on BigPresenter, I can get the card and/or its
presenter like this:

     | currentCard currentPresenter |
     currentCard := cardPresenter view currentCard.
     currentPresenter := cardPresenter presenterNamed: currentCard name.


-- Frank
[hidden email]

Davorin,

> After some poking around the image and Bill's DSDN, where I saw you were
> hooking-up directly to the view, not to the presenter. Is this "the way to
> do it" r just a short-cut?

That's the way to do it.

> If this is the way to do it, are there other typical cases when I am
> supposed to hook-up directly to the view insted of the presenter?

There are the number of classes where the View itself is normally its own
Presenter so to receive event notifications from them you do have to connect
to the View. The ones that spring to mind are Containers, Splitters,
Toolbars and StatusBars but I expect there are others.  I think the common
factor is that these are views that would not normally expect to interact
with the user, the job of the Presenter, and there is therefore no need for
a special class of Presenter.  It just falls down a bit with CardContainers
where the generic view (container) would not normally need to interact but
the specific case (card container) does.

Ian