Switching views?

Can anybody offer some advice as to the best way to switch from one view
to another.  These wouldn't be views on the same object, but different
views on different objects that need to be displayed in the same
physical area.  One view might be an image, and an underlying view might
have data about the image.

I've done similar things in VAST, with their SwitcherPane, but I don't
see anything similar in Dolphin.  If something exists, that would be
great.  If not, I would appreciate any ideas for how to construct what I
need.

Thanks
-Dan

-----------------
Dan Antion

Dan Antion wrote:
>
> I've done similar things in VAST, with their SwitcherPane, but I don't
> see anything similar in Dolphin.  If something exists, that would be
> great.  If not, I would appreciate any ideas for how to construct what I
> need.
>

I do something like this.  I can provide more details another time if
you need them (it's getting late here right now).

Basically, I have a ContainerView named 'container' in the window and
have methods like this:

createComponents
        super createComponents.
        container := self add: Presenter new name: 'container'.
        subPresenter := nil

showSubPresenterFor: anObject
        self removeCurrentSubPresenter.
        "somehow determine what kind of sub-presenter to show"
        "here we assume it's SubPresenter"
        subPresenter := SubPresenter createIn: container on: anObject.
        subPresenter view arrangement: #center "or whatever"

removeCurrentSubPresenter
        subPresenter isNil ifFalse: [container remove: subPresenter].
        subPresenter := nil

I hook things up so that showSubPresenterFor: gets called at the
appropriate time, and I have ways of determining what kind of
sub-presenter to show for each kind of object I might want to display in
there.

The key methods are Presenter>>createIn:on: and Presenter>>remove:.

Hope this helps,
Randy
--
Randy Coulman
NOTE: Reply-to: address is spam-guarded.  Reassemble the following to
reply directly:
rcoulman at charter dot net

Dan Antion wrote:

> Can anybody offer some advice as to the best way to switch from one view
> to another.  These wouldn't be views on the same object, but different
> views on different objects that need to be displayed in the same
> physical area.(Oddly, this came up just a couple of days ago)

I think that you are looking for a WizardCardContainer (Presenter.'Wizard card
container').  Add all your "variable" sub-components as children, and then
switch between them by sending #ensureVisible to the presenters.

    -- chris

Dan,

> I think that you are looking for a WizardCardContainer (Presenter.'Wizard card
> container').  Add all your "variable" sub-components as children, and then
> switch between them by sending #ensureVisible to the presenters.

I agree with Chris, but if that does not meet your needs, see Pane
Holders on my web site.  Either way, you might find my Wizardry package
helpful.

Have a good one,

Bill

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

Randy/all,

I am having a similar problem organizing a pluggable set of presenters in
the middle of a Shell.  I do not know what view to place there in the VC to
accommodate the subPresenters, which will be switched in and out by button
events in the Shell.  I assume that this view should be a ContainerView, as
you have outlined below.  Do you have any working code you can post?

There is another twist.  The different subPresenters, in my case, don't need
to be Presenters proper, because they don't react to keyboard and mouse
events.  They only show and manipulate text data in fields, in response to
button events in the Shell.  These Presenters then should be just Views.
Some of them have matching models, and some don't.

I don't want to draw each view in the VC.  Instead I want to use a subclass
of RichTextEdit whose size is fixed at x by y character cells, and
instantiate inside it several MyDataField instances that know what line they
belong on, their label, data, color, etc.  Horizontal arrangement is nominal
(not indexed) via #centered, #leftJustified, etc.  This feels a bit hackish,
but follows a simple pattern that makes it easier to compose than drawing
each view with VC.  Suggestions are welcome.

Shaping


"Randy Coulman" <[hidden email]> wrote in message
news:[hidden email]...

Shaping wrote:
>
> I am having a similar problem organizing a pluggable set of presenters in
> the middle of a Shell.  I do not know what view to place there in the VC to
> accommodate the subPresenters, which will be switched in and out by button
> events in the Shell.  I assume that this view should be a ContainerView, as
> you have outlined below.  Do you have any working code you can post?
>

The message you quoted contained the working code that I use to switch
sub-presenters in and out (see below). The view in the VC is, as you
suspect, Container view, which is associated with Presenter.  You'd hook
up your button events to call #showSubPresenterFor: (or some variant of
it) and everything should just work after that.

> There is another twist.  The different subPresenters, in my case, don't need
> to be Presenters proper, because they don't react to keyboard and mouse
> events.  They only show and manipulate text data in fields, in response to
> button events in the Shell.  These Presenters then should be just Views.
> Some of them have matching models, and some don't.
>

I haven't tried this, so I don't know what's possible here.

--
Randy Coulman
NOTE: Reply-to: address is spam-guarded.  Reassemble the following to
reply directly:
rcoulman at charter dot net

> The message you quoted contained the working code that I use to switch
> sub-presenters in and out (see below). The view in the VC is, as you
> suspect, Container view, which is associated with Presenter.

Which?  Container view has no matching presenter.  What Presenter do you add
to the Shell?

  You'd hook
> up your button events to call #showSubPresenterFor: (or some variant of
> it) and everything should just work after that.

showSubPresenterFor: what?  A model? The containing Presenter?


Regards,

Shaping

Shaping wrote:
>>The message you quoted contained the working code that I use to switch
>>sub-presenters in and out (see below). The view in the VC is, as you
>>suspect, Container view, which is associated with Presenter.
>
>
> Which?  Container view has no matching presenter.  What Presenter do you add
> to the Shell?
>

The associated presenter class for Container view is Presenter (the base
class).  IIRC, there used to be a separate CompositePresenter class, but
that has been folded into the base class in recent versions of Dolphin.

>   You'd hook
>
>>up your button events to call #showSubPresenterFor: (or some variant of
>>it) and everything should just work after that.
>
>
> showSubPresenterFor: what?  A model? The containing Presenter?
>

I pass in a model, which I have programmed to know what kind of
presenter to show.  I'd have to see more of your code to know how best
you should do it in your case.  Maybe the button that was clicked
indicates what kind of presenter to show, in which case, I might pass in
the sub-presenter class directly.

In any event, the important thing to know is the following call:

SubPresenterClass createIn: container on: aModel

Randy
--
Randy Coulman
NOTE: Reply-to: address is spam-guarded.  Reassemble the following to
reply directly:
rcoulman at charter dot net

Let's take a concrete, generic example.

In the VC, say we have MyShell with an empty view (resource/Presenter class
to be determined) in the top area and several buttons in the bottom.
Pressing some of the buttons puts a different View or Presenter in the empty
view "slot", and hooks up some of its methods to button-pressed events out
in the containing MyShell.  I say "View or Presenter" because the
#createComponents protocol seems to force us to add a Presenter to a MyShell
in order to link to a /drawn/, named View resource, which, in turn, results
in the creation of the corresponding View instance.  Yet some of the Views
in this example don't need Presenters because they don't respond directly to
mouse/keyboard events.  How do I handle this situation and why?  Do I make a
sort of dummy Presenter, anyway, for each View, so that I can abide by
#createComponents.

Another problem:  Say there are many pluggable Views that display, say, a
bunch of text fields.  The format of each View is a little different, but
they all fit into the same x-by-y character grid.  Specifying position and
format of each field using a MyField instance for each field in the View be
less work that drawing a great many separate View resources in the VC.  How
do I deal with this situation?  Would I build all of my Views as TextEdit
subclasses, and place the view resource for a TextEdit in the VC?  If so,
then how do I link to these View subclasses in #createComponents, if I have
no View resource by which to do so?  Can I specify a View class (instead of
a named View resource saved on a Presenter) directly in #createComponents?
Must I always add a Presenter in #createComponents?

If someone sees a way to do this programmatically without building View
resources, I think that would be a great help in clarifying what can be done
in this direction and what the potential problems in scope/comprehension
might be.  Presently I'm pounding on a big thick screw with a hammer.  Some
same code would help.  (Bill, I haven't looked at your GUI building stuff,
yet; will do that next.)


Shaping

> #createComponents protocol seems to force us to add a Presenter to a MyShell
> in order to link to a /drawn/, named View resource

FWIW, you don't have to have a presenter that corresponds to a named
view resource.  Rather, you can directly refer to any named view in
MyShell with
     MyShell view viewNamed: 'yourViewName'

-- Louis

> If someone sees a way to do this programmatically without building View
> resources, I think that would be a great help in clarifying what can be done
> in this direction and what the potential problems in scope/comprehension
> might be.  Presently I'm pounding on a big thick screw with a hammer.  Some
> same code would help.  (Bill, I haven't looked at your GUI building stuff,
> yet; will do that next.)

Another thing you should do is look at Pane Holders; in fact I suggest
that you do that first.  See VerticalPaneListPresnter class>>example to
see if it meets your needs.  ViewGenerator is another possibility, but
its mission in life is to "hard code" things as you would do yourself.

Is this for a deployed executable?  If not, you might start with the
PAI; I've used it in situations where I wanted a complex GUI for
little/no work.

Have a good one,

Bill

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

Shaping wrote:

> Presently I'm pounding on a big thick
> screw with a hammer.

I think you are right, and that you are making difficulties for yourself.

First off, I don't think you understand the role of the Presenter in an MVP
triad.  It's job is /not/ to interpret mouse/keyboard events (it sounds as if
you are thinking of it as merely the 'C' in MVC renamed).  I think the
Presenter's job can be described as that it owns the presentation layer (the
Model, of course, owns -- is! -- the domain layer), and that it /can/ delegate
some of the work (such as painting the UI, or interpreting user gestures, to
other standardised elements such as a View or an Interactor.

In any case Presenters are light-weight objects, so there's little practical
reason to avoid them.

It's worth mentioning, as an aside, that the role of a Presenter /as it is seen
by a View/ can be carried out by the View itself.  In fact if you use a View
raw, then its #presenter will be itself.  This is why Views work more-or-less
normally in the VC.  That also means that you /can/ use Views raw yourself
(most people do, for simple things like buttons and static text).  But if you
are trying to do anything significant using a Presenter-less View then you are
going against the grain of the system.  You will be missing out on the
pre-packaged functionality and so will have more work to do, and will also have
to know the existing framework in considerably greater detail than you would
otherwise need.

Anyway...

Are you sure that you want to create/delete components dynamically ?  From what
you've said, the list of "dynamic" elements that you want to switch in and out
is small and fixed in advance.  If that's the case then it would be much easier
simply to create all of them in the VC at once, all embedded in a
WizardCardContainer allowing you to switch between.  If you'd done that then
you could have had all this working in less time than you've spent writing any
of your questions ;-)

If -- for whatever reason (even just pure curiosity) -- you want to do it
dynamically, then you should create a "holder pane" in the VC and add/remove
its contents at runtime.  Its a slightly unfortunate side-effect of the fact
that all Presenters can now act as Composites that there is no /explicit/
CompositePresenter anymore.  What you should use (IMO) is a simple Presenter
(an instance of that class) hooked up to its named 'Container view' resource.
Call it "holder", say, and give it a BorderLayout in the VC.

Then create one or more Presenter subclasses that hook up to your various
specialised text grids.  You don't say how you are implementing them, whether
as custom View classes, or as a bunch of TextEdits with a GridLayout, or what.

Then you can use the code that Randy has already posted, or the code in Bill's
stuff, to swap elements in and out of the holder pane at runtime.

You can't (I think) create new sub-views in #createComponents because the main
View has not yet been created.  #createComponents is a little misleadingly
named since what it does is create /Presenters/ which will later be hooked up
with any Views.  If I wanted to create a bunch of sub-components from code then
I'd do it in #onViewAvailable.  For instance:

=================
onViewAvailable
    | rows cols |
    rows := 4.
    cols := 3.
    self view layoutManager
        rows: rows;
        columns: cols.
    textPresenters := OrderedCollection new.
    1 to: rows do: [:row | 1 to: cols do: [:col |
        | presenter |
        presenter := TextPresenter createIn: self.
        presenter value: ('%d x %d' sprintfWith: row with: col).
        textPresenters add: presenter]].
=================

That assumes that the container presenter is "self", but it could just as
easily be a subpresenter.  It also assumes that the container has been set up
(in the VC) with a GridLayout layout manager.

    -- chris

"Bill Schwab" <[hidden email]> wrote in message
news:cumrnf$1cfk$[hidden email]...
Ulitmately, yes.

  If not, you might start with the
> PAI;

PAI?

Does your old goodies package have the same code as the new?  Is the
installation procedure the only thing that has changed?  I already have a
directory for you under the image directory.  I prefer to use that one.\


Shaping

I think of Presenter as sensor/reactor/mediator for Views and Models, a bit
more than a controller.  I would also call that a "presentation layer".
This as a notation seems, though, a little misleading, because Views are
definitely involved in presentation, in the ordinary sense.

>
> In any case Presenters are light-weight objects, so there's little
> practical
> reason to avoid them.

Granted.  But that isn't the real issue.  The problem is the confusion
generated by attaching the View resource to the Presenter, instead of to the
View.  Andy and I discussed this many years ago.

Using a Presenter is fine.  I want to explicity link the Presenter to a new
instance of a View, by naming the View class, not the corresponding
resource.

Recall that the problem is actually having to /draw/ many resources I prefer
to /code/ in separate Views.  I can deal with the layer of Presenters, but
not with all of the drawing, which is not efficient in this case.

>
> Are you sure that you want to create/delete components dynamically ?  From
> what
> you've said, the list of "dynamic" elements that you want to switch in and
> out
> is small and fixed in advance.

There are dozens of Views.

The switched Views are themselves internally dynamic, but are controlled by
events in the Shell (a View's events would be wired to Shell PushButton
events when that View is installed).

I mentioned placement by MyField instances in the View.  This means that
each View would be coded not drawn.  These Views would be subclasses of base
View class, and will parametrize (formatting details) each MyField as it is
instantiated.  The base View will be a RichTextEdit.  I should be clear:  I
don't want to use VC if it compromises the architecture I want.  Presenters
are not a problem, but I prefer to read the structure of the app I have, and
then decide whether the whole is clear of confusing.

Let's change #createComponents to #createSubPresenters, to be clear.

And if I want to create all Presenters and Views programmatically...?   Has
anyone created a complex app in code only?


Shaping

> PAI?

Published aspect inspector.  It might work in a deployed setting, but
the average end user is unlikely to get along with it - I think??


> Does your old goodies package have the same code as the new?  

More or less.  There are a few improvements.


 > Is the
> installation procedure the only thing that has changed?  I already have a
> directory for you under the image directory.  I prefer to use that one.\

I think you can install and then simply move everything before loading
the packages.  Let me know how it goes.

Note that you will probably run into walkbacks over #selfOrReferee.  The
code is in Ian's archives, or Google might turn it up.  I need to split
my ultimate base package to fix it.

Have a good one,

Bill


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

Shaping wrote:

> I think of Presenter as sensor/reactor/mediator for Views and Models, a
> bit more than a controller.  I would also call that a "presentation
> layer". This as a notation seems, though, a little misleading, because
> Views are definitely involved in presentation, in the ordinary sense.

Hmm.  I think you are selling Presenter short, but it probably isn't worth
exploring further  for these purposes.


> The problem is the confusion
> generated by attaching the View resource to the Presenter, instead of to
> the View.  Andy and I discussed this many years ago.

In point of fact, you /can/ attach view resources to View classes -- see
PushButton for example.

However, in the general case, the role of a view resource is different from
that of a view class.  A view resource is a /configured/ instance of a View.
Very few of the view resources have the same settings as the corresponding
class's default instance.  And, of course, most resources /don't/ correspond to
any interesting View class -- of the 352 view resources defined in my image
this morning,  94 are instances of ShellView, 87 are instances of
ContainerView, 35 are instances of DialogView, and 17 are instances of Toolbar.
(By "instances of" I mean that the deSTB-ed object is an instance of that exact
class, not a subclass.)  In fact, over 60% have sub-views.

View resources are repositories of configuration information, not a way of
recording an association between a Presenter class and a View class.


> Using a Presenter is fine.  I want to explicity link the Presenter to a
> new instance of a View, by naming the View class, not the corresponding
> resource.

It might be a worthwhile extension to be allowed to specify a direct link to a
View class, meaning "create me an instance of a named class with its default
initialisation".  I suppose it could be implemented in a similar way to
ReferenceViews.  It would certainly make life a little simpler during
development of new View subclasses.

However such an extension does not currently exist, so you can either fight
against the system to try to create and wire up View instances directly, or you
can use the existing mechanism and just allow the system to instantiate a named
view resource.  I cannot see much benefit (I can't really see /any/ benefit) in
trying to take the first of these options.  If you /do/ want to do that then
you'll have to write a fair bit of extra framework code since Presenters
currently do not know how to make a View by instantiating a View class
directly.  (I had a pop at adding the extra stuff, but was obviously missing
something since the new View didn't get created as a child of the presenter's
View...  I suppose I could work out what additional steps are necessary, but --
as I say -- I can't see the point).


> > Are you sure that you want to create/delete components dynamically ?
> > From what
> > you've said, the list of "dynamic" elements that you want to switch in
> > and out
> > is small and fixed in advance.
>
> There are dozens of Views.

Fair enough.  Yes, I'd use code too in that case.


> I mentioned placement by MyField instances in the View.  This means that
> each View would be coded not drawn.  These Views would be subclasses of
> base View class, and will parametrize (formatting details) each MyField
> as it is instantiated.

Why bother with all the subclasses ?  They are not providing extra behaviour,
only holding different configuration.  You aren't using the system as it's
meant to be used if you do this.

Options:

1) Save a "vanilla" resource (an instance of the base class) as a view resource
(or use a pre-existing one), create many clones of that in your
#onViewAvailable method, and configure them then.

2) Write code to create and save named view resources with the relevant
configuration.  Execute it once, and then load those resources by name from
your #onViewAvailable.

3) Create all your multiplicity of redundant subclasses, give each a modified
#initialise method (there'd be no other differences between them I'd imagine).
And use code to install each as a named View Resources.

4) Instead of a multiplicity of redundant subclasses of RichTextEdit, use a
similar nest of RichTextPresenter subclasses, each of which inherits a vanilla
'Default view', but configures it in its #onViewAvailable.

To me (1) seems far easier and more natural, but if you prefer (2) then you can
use code like:

     |  ri v |
     ri := ResourceIdentifier
                class: SomePresenter
                name: 'some name'.
     ri owningClass addView: self asResource: ri name.
     v := ri load.
     v
            anAspect: 'fiddle';
            anotherAspect: true;
            ....
            yourself.
    ri save: v.

If you do (3) then you can add the resources to a Presenter class slightly more
simply, for each class evaluate:

    PresenterClass addView ViewClass asResource: 'some name'.

But I repeat that (1) seems the most transparent option to me.


> And if I want to create all Presenters and Views programmatically...?
> Has anyone created a complex app in code only?

I don't see any particular reason why you couldn't extend the code we've shown
you to do that.  You would, I think, have to start by creating a "blank"
ShellView by instantiating Shell.'default View'; but thereafter you could add
all your sub-components from code if you wish.  Personally I prefer to rough
out UIs in the VC and reserve code for cases where tedious repetition, onerous
calculation, or dynamic behaviour is required.  But if, say,  you have an
independent spec of the UI (something like XML perhaps) that you'd rather
parse/execute directly then I don't think that should be a problem to
implement.

    -- chris

> And if I want to create all Presenters and Views programmatically...?   Has
> anyone created a complex app in code only?

Indeed; that's how ViewGenerator got its start.  I can't say much about
what it generates, other than to describe it as "the form from hell".  A
subclass of ViewGenerator reads "meta data" to create the view resources
and propose code to drive it all.  In most circumstances, I simply
compile all of the proposed chunks.

At this point, we have offered you solutions that generate everying
(ViewGenerator), Chris' draw first then (re)generate tool, and various
options (Pane Holders and lightweight alternatives posted here) for
dynamic presentation.

Respectfully, you need to try them and choose for yourself, and/or roll
your own.  I suspect you will find, as the respective authors have, that
there is no one tool that fits every situation, hence the plethora of
options.

Have a good one,

Bill


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

>> The problem is the confusion
>> generated by attaching the View resource to the Presenter, instead of to
>> the View.  Andy and I discussed this many years ago.
>
> In point of fact, you /can/ attach view resources to View classes -- see
> PushButton for example.

This could be worse.  What do we intend to communicate to the uninitiated by
this
convention?

>
> However such an extension does not currently exist, so you can either
> fight

It looks simpler to me, despite the current infrastrucure surrounding
resources.

The Presenters will be created (their models must persist across view
changes),
but made visible at different times.  What to plug into and why is a vague
idea to me.

The views provide unique field counts and arrangements of fields:
speciation via #intialize only, in this case.

> only holding different configuration.  You aren't using the system as it's
> meant to be used if you do this.

Meant?  I'm creating Views programmatically.


>
> Options:
>
> 1) Save a "vanilla" resource (an instance of the base class) as a view
> resource
> (or use a pre-existing one), create many clones of that in your
> #onViewAvailable method, and configure them then.

Clones?

This was the plan.

>
> 4) Instead of a multiplicity of redundant subclasses of RichTextEdit, use
> a
> similar nest of RichTextPresenter subclasses, each of which inherits a
> vanilla
> 'Default view', but configures it in its #onViewAvailable.

Where do you trigger: #onViewAvailable?


Motivations for this are not yet clear enough.


  You would, I think, have to start by creating a "blank"
Not UML specs, a specific Smalltalk grammar for specifying Views and other
things.


Shaping

Shaping wrote:

> This could be worse.  What do we intend to communicate to the uninitiated
> by this convention?

You mean "could /not/ be worse" ?  Anyway, I don't know what it is intended to
communicate.  Is it a slightly unfortunate bit of ad-hocery, or is it an
example of the fact that the framework is more flexible than it appears at
first sight ?  I dunno...

(But, as it happens, I created a View class only yesterday that doesn't seem to
"want" its view resources to belong with any particular Presenter class.  I'm
currently dithering between attaching its resources to Presenter, creating a
special (but vacuous) Presenter subclass, attaching the resources to the View
class, or deciding that the system is trying to tell me that the View is too
abstract for resources to be useful, and that only more concrete subclasses
will have resources....)


> > However such an extension does not currently exist, so you can either
> > fight
>
> It looks simpler to me, despite the current infrastrucure surrounding
> resources.

Probably because you don't understand the framework and want to avoid
it.  Which is fair enough; you can program to the Windows API (with some help
from View classes) but you'll obviously be operating on your own...


> The Presenters will be created (their models must persist across view
> changes),
> but made visible at different times.  What to plug into and why is a vague
> idea to me.
[... and ...]
> Where do you trigger: #onViewAvailable?

I'm sorry, but I think we're starting to go around in circles.  I've tried to
explain, as best as I can, but I'll have one last shot.  Please actually /try/
this:

My earlier example of the onViewAvailable is an essentially complete example.
Create a Presenter subclass, call it AAAPresenter.  Give it an instvar called
textPresenters.  Use the VC to create new view resource for it.  Give the
ContainerView in the resource a #layoutManager of GridLayout.  Save the
resource as 'Default view'.  (We could have just inherited
Presenter.'defaultView' and set the #layoutManager from code instead -- but I
think this way makes it clearer what's going on).

We've now created a static framework into which we will dynamically plug a set
of dynamically configured sub-components.  We have, if you like, created the
socket into which we will plug things.

Now define a method against the AAAPresenter (this is just the same code as I
posted a couple of days back):
=================
onViewAvailable
    | rows cols |
    rows := 4.
    cols := 3.
    self view layoutManager
        rows: rows;
        columns: cols.
    textPresenters := OrderedCollection new.
    1 to: rows do: [:row | 1 to: cols do: [:col |
        | presenter |
        presenter := TextPresenter createIn: self.
        presenter value: ('%d x %d' sprintfWith: row with: col).
        textPresenters add: presenter]].
=================

And that's it.  Show the Presenter.  E.g. use the menu options or
evaluate:

    AAAPresenter show.

In a more complete application you could either have a dedicated Presenter
subclass that was itself responsible for managing the pluggable stuff (as in
the above code), or you could use a "vanilla" Presenter as the "hole" and add
stuff to it from code in a higher-level presenter.  Either way you'd also have
code to add/remove components at later stages of the application's lifecycle
(in response to button presses and so on) but I'm assuming that's obvious once
you know how to do it at all.


> > 1) Save a "vanilla" resource (an instance of the base class) as a view
> > resource
> > (or use a pre-existing one), create many clones of that in your
> > #onViewAvailable method, and configure them then.
>
> Clones?

That's how the system works.  A view resource is a template instance which is
cloned (copied) at runtime to create real views.


> > > And if I want to create all Presenters and Views programmatically...?
> > > Has anyone created a complex app in code only?
> >
> > I don't see any particular reason why you couldn't extend the code we've
> > shown you to do that.
>
> Motivations for this are not yet clear enough.

How about: because it's easy and is likely to work ?

    -- chris

>> This could be worse.  What do we intend to communicate to the uninitiated
>> by this convention?
>
> You mean "could /not/ be worse" ?  Anyway, I don't know what it is
> intended to
> communicate.  Is it a slightly unfortunate bit of ad-hocery, or is it an
> example of the fact that the framework is more flexible than it appears at
> first sight ?  I dunno...

Communication of the class hierarchy's intended pattern of use should be
evident in the basic choices for scoping Presenters, Views, and specific
versions of Views (resources).  Dolphin is fairly good in this respect, but
there are some problems in getting the concept and its exceptions/variations
across to the user smoothly.  I did in fact mean what was written.

I can't make a determination until I reactivate old memories.  I'll have to
trace carefully through the code again, and assess the overall pattern being
communicated in different strata, and gauge pattern
consistency/synergy/predictability.  I strive for a high degree of
grammatical pattern-uniformity, and usually succeed, except at or near the
bottom of the class hierarchy--an acceptable shortcoming for me now.

I rewrote most of the Dolphin's MVP pattern about seven years ago, to be
used programmatically.  I did not finish the task because of the way in
which the Windows API structure negatively impacted the class/idea stratum
closest to the metal.  I can probably live with this now, or find a happier
way to encapsulate it.  I need to do some tracing for a couple of weeks.
Kind of wish I hadn't thrown that code away...but perhaps it is best to
forget and start over.

Incidentally I moved the Dolphin MVP reformation project to VW where it
mutated into a Model-Shape pattern (no controllers or presenters), in which
Shapes innately could acquire controller ability.  The graphical resolution
of Shape extends to the pixel level, and composition is achieved by
successive, recursive subdivision of the client area, not by accretion and
overlay.  The pattern is simple to use and understand.  The problem is that
a very fast machine is needed for practical use of the pattern (these
machines exist now), and I have not extended it to 3D.

The point is that VW's low-level constraints are very few, and this make VW
a beautiful creature.  There are a dozen or so window-manager-related events
coming into the image through the input semaphore, and the rest is pure
Smalltalk and primitives.  This greatly aids experimenting with new
graphical-construction patterns.  However, it leaves you with a great deal
of work to do, to get a nice, practical UI.  For all the unpleasant Windows
machinery under the hood, Dolphin's UI still looks and works better
(overall) than VW's, but that is changing, too.  Tradeoffs and slug races.


I appreciate the richness of your expererienced decision process in these
MVP circles, but I don't want myself or the user of my class framework to
dither.  I wish to make the framework mostly dither free, even during the
earliest stages of investigation by a new user.  This is how I gauge the
quality of the pattern I'm choosing/shaping.

No, I just wanted to know when the view is actually considered to be open
(code-wise).
I found the spot today, tracing around.

> My earlier example of the onViewAvailable is an essentially complete
> example.

I'm not disputing this.  Thanks for the example.

> Create a Presenter subclass, call it AAAPresenter.  Give it an instvar
> called
> textPresenters.  Use the VC to create new view resource for it.  Give the
> ContainerView in the resource a #layoutManager of GridLayout.  Save the
> resource as 'Default view'.  (We could have just inherited
> Presenter.'defaultView' and set the #layoutManager from code instead --  
> but I
> think this way makes it clearer what's going on).

Though the ContainerView is graphically convenient, I'm supposing that we
could swap views dynamically without it.  Is that correct?


Yes, this much is clear, but I prefer to experiment with a completely
code-based MVP app, including creation of the ShellView.


>
> In a more complete application you could either have a dedicated Presenter
> subclass that was itself responsible for managing the pluggable stuff (as
> in
> the above code)

This is what will be done, but I do not wish to link with View resources.
This approach is to discover a more efficient pattern.  Presently, the
relationship between View Composer construction choices and linkage to
Presenter code is under-constrained (requiring some mental "dithering", at
times, as you've noted).

, or you could use a "vanilla" Presenter as the "hole" and add
Yes, I recall.

>
>
>> > > And if I want to create all Presenters and Views programmatically...?
>> > > Has anyone created a complex app in code only?
>> >
>> > I don't see any particular reason why you couldn't extend the code
>> > we've
>> > shown you to do that.

I need an overlapped window.  I think I know where to find one.

>>
>> Motivations for this are not yet clear enough.
>
> How about: because it's easy and is likely to work ?

Relative to Visual Studio's MFC?  Certainly.  But you see perhaps that I'm
pushing for finer, more systematic expression in computer language.

The specific examples you offer are helpful.  The pattern underlying them is
not easy enough for use by a broad, uninitiated programming audience not
already conforming to the set of memorized constraints you now fluently
exercise and enjoy.  These constraints are often difficult to master, and
can be removed, by stepping backward in the design process, far enough,
before advancing once again.  Most of us don't have the resources (mostly
time) for this.  These statements are not harsh criticism of Dolphin.  It's
a very fine environ, and I have much affection for it.  In fact I've
recommended it routinely.  I offer a fresh perspective from one who
acclimated to MVP and then mostly forgot it.  Much can be learned from
forgetting and relearning.


Shaping