setting the model of a TreePresenter in Dialog>>model:

I am having a Dialog with a TreePresenter in a variable called
directoriesPresenter, but when showing the dialog, the tree isn't seen. The
#model: method of the Dialog looks like this:

model: fileManager
    super model: fileManager
    directoriesPresenter model: fileManager directories

where FileManager>>directories answers a TreeModel which may change when the
dialog is open. When stepping through the method using the debugger, it
seems that the view of the TreePresenter isn't properly connected, since
when the #model: method starts, the view of the TreePresenter is a
DeafObject and the same is true after the method has finished. It looks like
you can't set the model of a TreePresenter like this. I've tested this in a
workspace also and the result is the same:

presenter := TreePresenter new.
model := TreeModel new.
model add: $A asChildOf: nil;
    add: $B asChildOf: $A.
presenter show

but this works as expected:

TreePresenter showOn: model


Any suggestions on how to solve this?

Regards,
Mikael Svane

Mikael,

> Any suggestions on how to solve this?

You're workspace example fails because you are not creating the
TreePresenter correctly. If you use the following, with the addition of the
line where you set the model which I assume was a typo, then it does work.

presenter := TreePresenter create.
model := TreeModel new.
model
    add: $A asChildOf: nil;
    add: $B asChildOf: $A.
presenter model: model.
presenter show

As regards you original problem. It should work? I just created a Shell
subclass, called Test, with the following three methods

Test>>createComponents
    super createComponents.
    treeP := self add: TreePresenter new name: 'tree'

Test>>model: aTreeModel
    super model: aTreeModel.
    treeP model: aTreeModel.

Test class>>defaultModel
    ^TreeModel new
        add: $A asChildOf: nil;
        add: $B asChildOf: $A;
        yourself

I added a a TreePresenter.Default view resource to the Shell's view (named
'tree') and when I ran it the tree showed up correctly.

All I can suggest is that you check the code again. Having a missing super
send or a slight misspelling in a views name won't cause an error and can
give the sort of results you are seeing.

One final thing to try is adding an #onViewOpened method and setting the
TreePresenters model there (after a super send). That is, more or less, the
final point in the initialisation of the view and if it can't be set there
then something else is wrong.

Ian

Ian (and Andy),

After having examined the methods of the Dialog, I have found the error. In
my #createComponents method, I had made the name of the TreePresenter a
Symbol instead of a String. A simple mistake that was very difficult to
find.

The View Composer is the only part of Dolphin that I don't quite like. MVP
is very good, but the View Composer makes it more difficult to understand
that is should have to be. If the View Composer could generate the code for
#createComponents, #model: and #createSchematicWiring, the entire MVP
concept would be easier to understand and much time would be saved.

The VC should be able to create the Presenter's #createComponents method
automatically as in Christopher J. Demers's CJDPresenterGenerator package.
The #model: method could be created if the VC had a dialog that allowed you
to assign a model aspect to each subpresenter. The #createSchematicWiring
method could be created if for each subpresenter you could select the
appropriate events from a list generated from the
#publishedEventsOfInstances methods.

Andy, is there any chance that any of these features will appear in a future
version of Dolphin?


Regards,
Mikael Svane

Mikael, Andy,

> The VC should be able to create the Presenter's #createComponents method
> automatically as in Christopher J. Demers's CJDPresenterGenerator package.

I agree that Dolphin could be more helpful to the MVP developer, and Chris'
generator is an important step in the right direction for many situations.
As a long-standing critic of Microsoft, it's nice for me to be able to give
them credit for getting something right on occaision - here's an example
(mark your calendards<g>).  VC++ arrived on the scene with two wizards: one
(AppWizard) for setting up an application (with a make file and other
uglinesses that Dolphin thankfully helps us avoid), and another
(ClassWizard) for creating and tweaking UI (and other) elements of an
existing app.  Things would be different in Dolphin, but, I still think that
a similar split will be required.

One might think of Chris' solution as being analogous to the AppWizard;
though that's not really fair because he does allow for regeneration.
Another approach would be to add a few wizards to the VC to tweak an
existing view/presenter.

Yet another approach to automatic code geneation is to start from meta data
and build up the view resource and presenter code at the same time.  That's
the approach that I use and have made partially available.  However, my
system expects to be driven from a schema of some sort; it provides the
tools to build a complex view resource and then generate code for the entire
thing, but, doesn't do anything useful without some hacking for a particular
problem.  I'm not as careful as Chris about preserving changes.  My goal was
to reduce errors by having the machine do all of the grunt work; that's most
appropriate for big views with lots of simple aspects and a ready source of
type information.

Ian made some excellent suggestions based on an early version (probably more
or less what's on my web site now).  I've since acted on many of his
suggestions, and added a VC clone that has no PAI, making generation a lot
faster, and preventing resource starvation problems on Win9x.  The original
system would leave a lot of finalizable garbage and choke on very complex
views.  Among other things, I'd want to run the VC clone by OA to make sure
they don't object to its release; my hunch is they won't mind, but, it's
their call.  Beyond that, my GUI for presenting the code changes that will
be made is pretty horrible, but, it seems to work.

It's worth repeating that my generator kernel is not of much use as-is.  It
needs to be extended slightly to fit a particular class of problem.  With an
appropriate front end, it could be useful to beginners, and it's real
purpose is to pound out BIG views from meta data.


> The #model: method could be created if the VC had a dialog that allowed
you
> to assign a model aspect to each subpresenter.

There are few important caveats that would need to be tolerated if not
actively supported.  It would have to allow a presenter to use its default
model; for things that have meaning only in the GUI, it's often enough to
use #value[:] to interact with the user through one or more subpresenters.
There's a distinction between value presenters and composites.  Value
presenters will often connect via an aspect value adaptor; composites might
connect to a sub-model.  In other situations, I've had to create domain
objects that contain their own value models and expose them for use by
presenters and other domain objects; this is especially true for domain
objects that do calculations themselves rather than leaving it to a
presenter.  Sometimes it's helpful to present the same aspect in more than
one place (e.g. on "different ends" of a lengthy wizard); while I woudn't
expect a code generator to create that kind of structure, I would ask it to
not destroy it when I later add another subpresenter.  Chris' system would
probably regenerate around the manual edits.


> The #createSchematicWiring
> method could be created if for each subpresenter you could select the
> appropriate events from a list generated from the
> #publishedEventsOfInstances methods.

I suspect this is a little tricky, at least to do well.  A default selector
based on view name and event should be easy enough, but, that would not
always be the best approach.

Have a good one,

Bill

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