[D5.1] Removing subpresenters with reference views.

Hi all,

 I have a Presenter with a WizardCardContainer so I can put in the
WizarCardContainer several presenters as reference to show whenever
it's nedded.

 The question is that I'm sending to remove them with this code:

        monitor subPresenters do:[:subPresenter| monitor remove:
subPresenter].

 where #monitor is the WizardCardContainer, and the #remove: fails.

 Is that a bug in the referenceViews or I'm missing something?

 It throws an assertion faliure when reaches this:

>>removeSubView: aView
        "Removes aView as a subview of the receiver. The removed view is
destroyed"

        "Validate that aView is indeed one of the receiver's subviews"
        self assert: [aView parentView == self].     <<=================
        ^aView destroy; yourself

  the #== fails

  I'll try not removing them, but hiding them, but I think that the
previous idea should work. Don't you?

  regards,

Sebastián

Sebastián:

Try:

monitor subPresenters do:[:subPresenter| subPresenter view close].

But i'm not sure because i do not have D5 here with me.

regards bruno

Sebastián,

>  I have a Presenter with a WizardCardContainer so I can put in the
> WizarCardContainer several presenters as reference to show whenever
> it's nedded.

<shamelessPlug>Take a look at my Pane Holders package; it might do
everything you need.</shamelessPlug>


>  The question is that I'm sending to remove them with this code:
>
> monitor subPresenters do:[:subPresenter| monitor remove:
> subPresenter].
>
>  where #monitor is the WizardCardContainer, and the #remove: fails.
>
>  Is that a bug in the referenceViews or I'm missing something?

I'm not sure.  Look at the view and presenter hierarchies; Ian's Snoop
is very helpful in situations like this, though you can also "rough it"
using inspectors.  You might simply be trying to snip them out of
something a level or two above the parent view.

Reference views can also be a little tricky at times.  Note the #referee
aspect.  I have defined #selfOrReferee in a couple of places (the
archives should include the methods) for situations where I make heavy
use of reference views and yet care about the details of the view
heirarchy (or more accurately, prefer not to be bothered with the
details<g>).

Have a good one,

Bill


--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Sebastián,

> monitor subPresenters do:[:subPresenter| monitor remove:
> subPresenter].
>
>  where #monitor is the WizardCardContainer, and the #remove: fails.
>
>  Is that a bug in the referenceViews or I'm missing something?

I think it's a bug in the MVP framework.

If I understand you correctly, you have a WizardCardContainer and are adding
and removing cards dynamically.  If so then I don't see that you are getting
any advantage from using reference views as the top-level components displayed
in each card.  You might just as well create the referred-to ViewResource as
the topmost component.

FWIW, several of my things use exactly that architecture (without reference
views), and it works well for me.

    -- chris

Thanks everyone for your answers.
Dear Chris, the main advantage of using reference views is to change
the resource in one unique place every time is needed. I do it this way
because I want to do maintenance to the less resources as possible.
Thanks again,
Sebastian

Sebastián,

> Dear Chris, the main advantage of using reference views is to change
> the resource in one unique place every time is needed. I do it this way
> because I want to do maintenance to the less resources as possible.

I still don't get it.  I use reference views too, and for exactly the same
reason -- but I don't see how that reasoning applies here.

If I'm building a tabbed UI in the VC, then I'll very likely want to make each
"page" a separate (independent) view, and would probably make each tab a
reference view to the corresponding real view.  (Actually I would probably use
a trivial "real" view as the top-level of each tab and have that /contain/ a
reference view as its only contents -- I've found that tends to avoid the odd
problem.)

But in this case, if I understand you correctly, you are filling in the tabs
from /code/ not in the VC.  So your code can either refer to the reference
view, or it can refer directly to the view that is referenced.  Each is as
simple as the other.  In this case reference views are not giving you any extra
flexibility, but they are exposing you to a bug in the framework, so why use
them ?

Maybe I'm just misunderstanding what you are trying to do ?

    -- chris

Chris, perhaps I wasn't clear enough. I'll try to be more clear: as a
workarroung I've made the card container to have all the tabs as
reference views (as you do), with the first one as the most probable to
be shown first. Also, I've made that the activation of each one is made
dinamically (where activation means to actually attach a proper
presenter and a model for that tab and show it's view in a dynamic
way).

Regards,

Sebastian

Sebastián,

> Chris, perhaps I wasn't clear enough. I'll try to be more clear: as a
> workarroung I've made the card container to have all the tabs as
> reference views (as you do), with the first one as the most probable to
> be shown first. Also, I've made that the activation of each one is made
> dinamically (where activation means to actually attach a proper
> presenter and a model for that tab and show it's view in a dynamic
> way).

Well, I still don't understand, I'm afraid.  But since you have a working fix,
/and/ understand why the fix works (which is always nice!), it seems this story
had a happy ending :-)

    -- chris