Dinamic View

Hello

Im working with Dolphin Smalltalk. I have a view with menu on the
left. And I want that when I select an options of the menu, refresh
the view on the right. What can I do ?
 
I need actualize the view dinamically. Anyone have a solution ?

Thanks !!!  

Valeria,

Valeria,

 > Im working with Dolphin Smalltalk. I have a view with menu on the
 > left. And I want that when I select an options of the menu, refresh
 > the view on the right. What can I do ?
 >
 > I need actualize the view dinamically. Anyone have a solution ?

What you should do depends in part on the type of presenter/view pair
that needs to update.  For some time, the official answer has been (or
at least was) that MVP triads were created as a unit, and changing the
model "on the fly" is risky at best.  However, see
DocumentShell>>setDocumentData:.

Note that value presenters avoid the problems, because one can simply
set the value of the model.  Also, many views in the base system respond
well to #refreshContents.

Finally, you can use my Pane Holders package, which includes a few
different kinds of presenters that act as placeholders for other
presenters that can be changed on the fly.  Most of the detail was
stolen from Dolphin's various inspectors.  My suggestion is to start
with Pane Holders and then move away from it, or not, as you gain
experience with MVP.

Have a good one,

Bill

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

Bill Schwab wrote:

> For some time, the official answer has been (or
> at least was) that MVP triads were created as a unit, and changing the
> model "on the fly" is risky at best.

Personally, I do this all the time, and it works very well.

    -- chris

Valeria wrote:

> Im working with Dolphin Smalltalk. I have a view with menu on the
> left. And I want that when I select an options of the menu, refresh
> the view on the right. What can I do ?
>
> I need actualize the view dinamically. Anyone have a solution ?

It's sometimes easier just to use a WizardCardContainer (resource named 'Wizard
card container' of Presenter) that you've set up (in the View Composer) with
all the different possible Views as different 'cards', and then switch between
them programmatically as the user changes the selection in the list.

If that isn't suitable, or you just want to do it dynamically, then the
following code illustrates adding and removing MVP components on the fly, you
can try this out by evaluating the 5 steps in a workspace:

    "1) create the model we will use, and a shell to show it in"
    model := ListModel on: (1 to: 10 by: 0.37).
    shell := Shell show.
    shell view layoutManager: BorderLayout new.

    "2) now create and add a sub-Presenter and View to show the Model"
    presenter := ListPresenter
                            create: 'Enhanced list view'
                            in: shell
                            on: model.
    presenter view arrangement: #center; invalidate.

    "3) now remove them again"
    shell remove: presenter.

    "4) new create and add a different Presenter/View on the same model"
    presenter := ListPresenter
                            create: 'Tab view'
                            in: shell
                            on: model.
    presenter view arrangement: #center; invalidate.

    "5) and remove them again"
    shell remove: presenter.

HTH

    -- chris

Chris,

> > For some time, the official answer has been (or
> > at least was) that MVP triads were created as a unit, and changing the
> > model "on the fly" is risky at best.
>
> Personally, I do this all the time, and it works very well.

The biggest problem is see is with trigger wiring.  If the "old model" and
other event sources are gc'd after the change, then the weak event system
will forget about them.  But how can you be certain that there are not
unwanted side effects from old registrations?  AFAIK, OA never blessed using
#model: to change models, though they do it on occaision (e.g.
DocumentShell).  Pane Holders is perhaps overkill, but it treats triads as
units.

Have a good one,

Bill

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

Bill,

> > > For some time, the official answer has been (or
> > > at least was) that MVP triads were created as a unit, and changing the
> > > model "on the fly" is risky at best.
> >
> > Personally, I do this all the time, and it works very well.
>
> The biggest problem is see is with trigger wiring.

Agreed that that takes handling.  I use code like:

============
model: aModel
    self declineEventsFromModel.
    super mode: aModel.
    self solciitEventsFromModel.
    "and then any other settup..."
============

which is hardly a big effort (especially as "declineEventsFromModel" tends to
be just
    self model removeEventsTriggeredFor: self.
)


> AFAIK, OA never blessed
> using #model: to change models, though they do it on occaision (e.g.
> DocumentShell).  Pane Holders is perhaps overkill, but it treats triads as
> units.

Yes, but there are far too many problems that just can't be solved (reasonably)
any other way.  So I just allow setting the model everywhere, and it's caused
no special problems so far[*].

    -- chris

[*]  Here and there I've been forced to put:
        self model self model
into #onViewOpened, but that's because of the occasional problems caused by the
use of a DeafObject during setup, rather than being specific to the way I use
models, I think (though I'd have to go back and look).