Pluggable Presenters

I'm using an OGL View and Presenter for rendering.  I have several
subclasses of Presenter, each of which is created when plugged into the
Presenter/ContainerView in #onViewAvailable.  This seems to go with the
existing machinery a little better, but I'm not sure.  I don't see a way to
plug in a Presenter instance and attach it to a view, without mucking with a
lot of code, something I don't want to do now.

The model situation is complex.  The OGL Presenter needs a World model
(scene graph), so I cannot feed it a basic number-and-string model (as from
a database, for example).  I do a series of transformations on the fly where
I convert the basic domain model to a graphical part, plug the part into a
World, and then pass the world into the OGL Presenter's #model:.  I'm having
to override #on: on the specific presenter class, to do this extra model
conversion.  It seems a little awkward.  I think I may also need to
specialize #connectView, which otherwise would plug in the basic domain
model.

There are many places where models are plugged.  At the OGL presenter level,
a submodel of the main model is plugged in.  Backing out one level, nil is
plugged in for the Container's model.  And finally back at the Shell, the
full model is plugged in, but this only needed for passing out little
submodels to the pluggable presenters.

The order in which views are created and models are plugged produces
limitations on what can be done and when.  Are there published guidelines on
what should and should not be attempted in #onViewAvailable and
#onViewOpened?



Shaping

Shaping wrote:

> The model situation is complex.  The OGL Presenter needs a World model
> (scene graph), so I cannot feed it a basic number-and-string model (as
> from a database, for example).  I do a series of transformations on the
> fly where I convert the basic domain model to a graphical part, plug the
> part into a World, and then pass the world into the OGL Presenter's
> #model:.  I'm having to override #on: on the specific presenter class, to
> do this extra model conversion.  It seems a little awkward.

I may not be understanding you but it sounds as if you need two layers of
models and probably three layers of componentry.

I'm assuming that you have a main Model that is a collection of raw data, from
which various scene graphs can be derived.  And you have a generic capability
to display OGL in a component (a generic Presenter/View pair that takes an
arbitrary scene graph as a model).

If (the simple, or perhaps simplistic, case) the generic OGL component is
sufficient by itself (undecorated, but maybe with settings changes) to
implement the complete UI to each derived scene, then I'd guess that the
following would work:

    Main component (shell or high-level presenter) is has the raw data
    as its model.  It knows how to derive specialised world-views (scene
    graphs) from the raw data.  It extracts these and hands them to
    instances of the generic OGL component to use as their models.

In the more likely case that the specialised world-views want different
decorations (different sets of command buttons, and the like), or if the job of
extracting the scene from the raw data shouldn't be centralised in one object,
you would add an extra layer of components.  In this case you have:

    Main component (shell or high-level presenter) has the raw data
    as its model.  It's pretty dumb, it only knows how to plug one of
    a list of sub-Presenters into its "hole".  In all cases it just passes
    them the same model as it itself is using.

    You have an extensible collection of sub-presenter classes.  Each
    of which takes the raw data as its model, and extracts a derived
    scene graph from that data and passes it to an embedded instance
    of the generic OGL components.  These presenters' Views also
    include (besides the embedded OGL thingy) any decorations that
    are appropriate for that particular purpose.

Assuming the latter case, each specialised Presenter (I'll call 'em "Pages" --
I'll explain why in a mo'), would have one or more instvars that held the
derived scene and related data, but would not use the derived scene as its own
model.  To implement that, something like:

    model: aRawData
        super model: aRawData.
        scene := extractSceneFrom: self model.
        (self presenterNamed: 'OGL') model: scene.

So all the different Pages take the same model, but are responsible for
presenting different aspects of that data.  Some might not even use the OGL
stuff at all.

This is an architecture (plugability and all) that I have used several times.
So often that I turned it into a small framework (the 'PolyViewer' stuff that's
on my website -- albeit still in the 'unpublished' category).  An application
consists of a Shell with a Model, plus a tabbed collection of 'Pages' (the
collection is dynamically configured and user-settable) each of which shares
the main Model, but allows the user to interact with a different aspect of that
Model.  It works very well for me (although my actual code is very old, and
could do with some cleanup and correction).

(BTW, you may see from this why I say that the Presenter has a much more
important role than I think you were allowing it.)

    -- chris

Thanks.

This seems reasonable, but I could not get it work.  I locked-up the image
all day long, apparently by adding a
Presenter/ContainerView-round-OpenGLPresenter/OpenGLView nesting (drawn in
VC) inside a MyShell/ShellView-round-Presenter/ContainerView (drawn in VC).
Too many degrees of freedom in the present implementation of MVP preclude
consistent, realiable choices in complex composition scenarios.  I am sure
that I can correct this problem, once I'm fully reacquainted with the
snag-zone.  This could take a few weeks.

The domain model and matching World model are in the right classes,
now--feels good or at least acceptable.  But by the time I got them there, I
could no longer reach (by name on the correct Presenter) the OGL resource at
the third level in the original resource on the original Shell.  So I broke
up that original resource across two presenters.  The
Shell-round-Container-round-OpenGLPresenter became Shell-round-Container)
and I put a Container-round-OpenGLPresenter resource on the middle-tier
Presenter (MyPagePresenter) (still holding a domain model; the world goes in
the third tier in the OpenGL Presenter).  Possibly, we can remove the second
container, which seems to be a graphical pluggablility convention, not
sure--seems to be for more than formatting convenience.  I'll do some more
experiments.  Suggestions are welcome.  So far I've not been able
dynamically to plug-in a presenter whose view then works, using two layers
of Model (domain, World), and three layers of Presenter (domain, domain,
World).


Shaping

Shaping wrote:

> This seems reasonable, but I could not get it work.  I locked-up the image
> all day long, apparently by adding a [...]

My immediate guess is that its a problem to do with OGL rather than with your
architecture (unless you are inadvertantly ommiting some intialisation).  If so
then you are lucky that it only locked up Dolphin.  On my machine OGL ends up
using DirectxX (I believe) and that tends to lock-up the kernel -- hard...


> Suggestions are welcome.  So far I've not been able
> dynamically to plug-in a presenter whose view then works, using two layers
> of Model (domain, World), and three layers of Presenter (domain, domain,
> World).

As a sanity check, and maybe as a source of comparisons, I've put together a
little package that uses the same architecture as I've been discussing, except
that it uses an intermediate layer of Presenters as you described.  The shell
takes an object as a model and passes it to its PlugholePresenter.  The
plughole is where PlugholePages can be plugged.  They share the model with the
main shell and plughole, but extract some data from it and use an embedded
TextPresenter+view (as an analogue of your OGL-presenter+view) to display that.

It'll be here:
    http://ephemera.metagnostic.org/code/Plughole.pac.zip
until I remember to remove it again.

    -- chris

I tried it, but don't see any plugging of presenters.  Did you test?  I also
tried it in a clean image with path 4 installed.  Still nothing.

I traced through the code.  It seems to be doing what it should (code-wise),
including the rendering of text in static fields, but nothing appears but
the  drop-down list of two items.

Shaping


"Chris Uppal" <[hidden email]> wrote in message
news:42188cc7$0$38039$[hidden email]...

Shaping wrote:

> I tried it, but don't see any plugging of presenters.  Did you test?

Naturally (sheesh!).

Stick a #halt in PlugholeShell>>onPluginChanged, select something from the
drop-list, and follow it from there.

Would I lie to you ?  /In pink/ ??

;-)

    -- chris

>> I tried it, but don't see any plugging of presenters.  Did you test?
>
> Naturally (sheesh!).

I thought so.  Try loading your own package into a clean image with patches.

>
> Stick a #halt in PlugholeShell>>onPluginChanged, select something from the
> drop-list, and follow it from there.

I did just that to do the tracing I mentioned.  I don't understand.  I
loaded the package into a virgin image plus leve-4 patch and evaluated

PlugholeShell show.

I get the Shell with the pink background and the dropdown.  When I select a
item, nothing happens in the pane below.


> Would I lie to you ?  /In pink/ ??

I would not think so.

I have my OGL sort of working.  The problem is that you need to have some
exceptional logic for when to use the domain model or the World.  I found my
problem by simplifying the test scenario, by showing the PagePresenter in a
surrogate shell.  But when I put it back in the Shell, model logic has to be
changed very carefully.  You must have world where you once had a domain
model, because the latter doesn't know what to do with a camera.  Still
investigating the best way to do this.

Shaping

[Very quick reply as it's late (my time), but I'll probably be off-air for a
day or two, so...]

Shaping wrote:

> PlugholeShell show.

Aha! You obviously did not read the very copious package and class comments in
which it is clearly implied that you have to provide an interesting object to
be the Model.  ;-)

Actually, I suspect that the (known) bug in the Dolphin framework that stops it
initialising a triad properly when the model is nil is at work here, but I
don't have time to check just now (and I can't remember the details anyway).


> I have my OGL sort of working.  The problem is [...]

Good.  You seem to have cracked it; it sounds as if the remaining problems are
"just code".

    -- chris

> Shaping wrote:
>
>> PlugholeShell show.
>
> Aha! You obviously did not read the very copious package and class
> comments in
> which it is clearly implied that you have to provide an interesting object
> to
> be the Model.  ;-)

I assumed a defaultModel, as usual.

"Coding convention" might be a better way to frame it.

See the other posting on #onViewOpened and #onViewAvailable.  I'm concerned
about the ordering of rendering.  #view: and #onViewOpened drill down left
recursively, triggering events that lead to rendering (at least in my OGL
stuff).


Shaping

How necessary is your use of the ReferenceView as the holder of the plugged
Presenter?  I do not have the intermediate PlugholePresenter.  I just draw a
container view on my shell and link the container view to an instance of
Presenter.  Perhaps this is the problem.

Shaping

Shaping wrote:

> How necessary is your use of the ReferenceView as the holder of the
> plugged Presenter?

I can't see any reason it would make a difference, it's just the way I happened
to code it (I use reference views as a matter of course).

    -- chris