Presenters without views

Hi...

somewhere I read that the MVP is powerful for it's ability to allow complex
and simple composite views as required, e.g. a simple window and a
complicated one depending on the resource used (i.e. schosen by the resource
name).

I now tried this, built a complicated composite view resource and afterwards
deleted the complicated stuff, revised the layout and saved under a
different name.

Unfrtunately, now Dolphin crashes after a short while of unresponsiveness
and a heap of "Could not display walkback" messages in the Transcript.
I tracked down the problem to be that at least one of my unbound
subpresenters (also composite but ContainerView, and no view with its name
in the resource) gets the top level shellview attached?! Thereafter a couple
of Shell-specific events are delivered to the presenter, which is of course
not at all a Shell- but a Presenter-subclass.

This code in Presenter>>view: (appended in full) looks particularly strange
to me:
...
ifFalse:
["No matching sub view - drill down one more layer"
eachSubPresenter subPresenters notEmpty
ifTrue: [eachSubPresenter view: aView]]].
view := aView.
...
As this is recursive, eventually the toplevel shell view (aView) is reaching
my presenter and is assigned to its view instance var unconditionally (last
row).

BTW: I wanted to check with "myPresenter hasView" to check if a view is
actually in the resource for my presenter, but this does not work either
apparently if my Shell is attached.

Any help highly appreciated!

Ciao

...Jochen


----------------------------------------------------------------------------
------------------
view: aView
"Set the view for the receiver to aView. We also connect up any sub-views
to same named presenters in our subPresenters collection"
"Now run through all our sub-presenters and connect them in turn
to same named sub-views within aView.
N.B. If subPresenters is nil at this point, you might have forgotten
a supersend in your presenter's #initialize method."
| name matchingSubView |
self subPresenters do:
[:eachSubPresenter |
name := self nameOf: eachSubPresenter.
matchingSubView := aView viewNamed: name ifNone: [].
matchingSubView notNil
ifTrue: [eachSubPresenter view: matchingSubView presenterConnectionPoint]
ifFalse:
["No matching sub view - drill down one more layer"
eachSubPresenter subPresenters notEmpty
ifTrue: [eachSubPresenter view: aView]]].
view := aView.
self onViewAvailable.
self connectView

Jochen Riekhof wrote:

I tracked down the problem to be that at least one
> of my unbound subpresenters (also composite but ContainerView, and no
> view with its name in the resource) gets the top level shellview
> attached?

I haven't tried to reproduce this, but -- just as a guess -- is it possible
that one of your subpresenters has the same name (nil) as the top level shell ?
If so, then it shouldn't ;-)

    -- chris

> I haven't tried to reproduce this, but -- just as a guess -- is it
possible
> that one of your subpresenters has the same name (nil) as the top level
shell ?
> If so, then it shouldn't ;-)

Nope, don't think so, all presenters have names. Do you mean you can add
with
add: SomePresenter new name: nil
?. Never tried this one...

Ciao

...Jochen

Jochen Riekhof wrote:
>> I[...]s it
>> possible that one of your subpresenters has the same name (nil) as
>> the top level shell ? If so, then it shouldn't ;-)
>
> Nope, don't think so, all presenters have names.

One way is:

    self subPresenters add: Presenter new.

But the question is not, "can it be done ?", but "is it causing your
problem ?".  Having looked at it a bit more, I doubt if it is.

In fact I agree that the #view: implementation is screwy; it will leave all
unbound Presenters, that themselves have sub-presenters, "thinking" that they
are connected to Views -- in fact the same Views as their parents.

It doesn't normally cause problems because the parent takes control of the View
*after* the child has wrongly done so, but I still think it's a bug.  E.g. the
View can end up with the child's Model if the parent's Model is nil at the time
this happens.

    -- chris

>     self subPresenters add: Presenter new.

Yucc ;-).


> In fact I agree that the #view: implementation is screwy; it will leave
all
> unbound Presenters, that themselves have sub-presenters, "thinking" that
they
> are connected to Views -- in fact the same Views as their parents.

Yep, to me it looks like Presenter>>view: has two incompatible
responsibilities: setting the view (intended) and attaching subviews to
subPresenters (untintended on tree traversal except for root). If I have
time tomorrow i will split the method in a
Presenter>>attachSubPresentersToViews: and a lighterweight Presenter>>view:
method. Will report then...

Ciao

...Jochen

Was not so difficult, did it already. All stuff I opened so far seems to
work as before, and in addition my problem is fixed. Here is what I changed:

First, I added method Presenter>>attachSubPresenterViews:

<CODE CLASS= Presenter>
attachSubPresenterViews: aView
"Connect up any sub-views to same named presenters in our subPresenters
collection"
"Now run through all our sub-presenters and connect them in turn
to same named sub-views within aView.
N.B. If subPresenters is nil at this point, you might have forgotten
a supersend in your presenter's #initialize method."
| name matchingSubView |
self subPresenters do:
[:eachSubPresenter |
name := self nameOf: eachSubPresenter.
matchingSubView := aView viewNamed: name ifNone: [].
matchingSubView notNil
ifTrue: [eachSubPresenter view: matchingSubView presenterConnectionPoint]
ifFalse:
["No matching sub view - drill down one more layer"
eachSubPresenter subPresenters notEmpty
ifTrue: [eachSubPresenter attachSubPresenterViews: aView]]]
</CODE>


The change here is to call attachSubPresenterViews: instead of view: when no
correspondingly named view is found for a subpresenter. Then, changed method
Presenter>>view: to be:

<CODE CLASS= Presenter>
view: aView
"Set the view for the receiver to aView. We also call
attachSubPresenterViews:
to connect up any sub-views to same named presenters in our subPresenters
collection"
self attachSubPresenterViews: aView.
view := aView.
self onViewAvailable.
self connectView.
</CODE>

Would be interested if Andy or Blair see any problems with this change....

Ciao

...Jochen

Jochen Riekhof wrote:

> Was not so difficult, did it already. All stuff I opened so far seems
> to work as before, and in addition my problem is fixed. Here is what
> I changed:

Looks plausible to me.

I question the need for the:
    eachSubPresenter subPresenters notEmpty ifTrue:
test, though -- seems redundant.

    -- chris

> I question the need for the:
>     eachSubPresenter subPresenters notEmpty ifTrue:
> test, though -- seems redundant.

You are right (just copied it from the old version). Maybe intent was to
save some method calls?

Ciao

...Jochen

Jochen,

> > I question the need for the:
> >     eachSubPresenter subPresenters notEmpty ifTrue:
> > test, though -- seems redundant.
>
> You are right (just copied it from the old version). Maybe intent was to
> save some method calls?

Thanks for the report and the proposed fix. This has been recorded as issue
#1141 and your fix will appear in PL2.

Best Regards,

Andy Bower
Dolphin Support
http://www.object-arts.com
---
Are you trying too hard?
http://www.object-arts.com/Relax.htm
---