Learning MVP in Dolphin 5 Trial

Hi,

I am in the process of evaluating Dolphin 5 for our group. But I can
having a hard time understanding the latest incarnation of MVP in
Dolphin 5. Most of the tutorials that I was able to find on the
internet refer to older versions of Dolphin such as version 3 and 4.

I have been working with the PersonalMoney tutorial (based on version
4 Education Centre) and compared it to the sample in version 5. I do
not grok the #createSchematicWiring concept.

Any pointers on this would be appreciated!

thanks,
Larry Trutter

Larry Trutter wrote:

> I am in the process of evaluating Dolphin 5 for our group. But I can
> having a hard time understanding the latest incarnation of MVP in
> Dolphin 5. Most of the tutorials that I was able to find on the
> internet refer to older versions of Dolphin such as version 3 and 4.

I don't think there's a lot of difference between D4 and D5 in the MVP area.
I'd expect nearly all code to work unchanged, and still to be in the
"preferred style".  There were a few additions to the framework , but they
shouldn't affect beginners much, if at all.

> I have been working with the PersonalMoney tutorial (based on version
> 4 Education Centre) and compared it to the sample in version 5. I do
> not grok the #createSchematicWiring concept.

I don't currently have the D4 education centre, or the D5 PersonalMoney
sample to hand, so I don't know what the differences are.  A quick
explanation of #createSchematicWiring (which probably duplicates what you've
already seen, and will therefore be useless ;-( ) could run as follows.

#createSchematicWiring (which is -- for historical reasons -- *very* badly
named) is the place where you would normally put the code that coordinates
the various sub-components of your application.  The sub-components generate
events notifying any listeners of changes to their state; you arrange to be
a listener, and to take appropriate action when those events occur.  For
instance if you wanted the user to be able to change the app window's title
by selecting from in a list, then your implementation of
#createSchematicWiring might look like:

MyApp>>createSchematicWiring
    super createSchematicWiring.
    (self presenterNamed: 'TitleList')
        when: #selectionChanged:
        send: #onTitleSelected
        to: self.

which would be called automatically during application startup, and arranges
that when the subcomponent called 'TitleList' (assumed to be some sort of
ListPresenter presenting a list of Strings) has its selection changed, then
the system will invoke you apps #onTitleSelected method.  That in turn might
look like:

MyApp>>onTitleSelected
    | newTitle |
    newTitle := (self presenterNamed: 'TitleList') selectionIfNone: ['<No
Title>'].
    self caption: newTitle.

There are *lots* of examples in the standard image.  If you look you'll see
that they all follow a very similar sort of pattern.

    -- chris

Folks,

[snip].

> #createSchematicWiring (which is -- for historical reasons -- *very* badly
> named) is the place where you would normally put the code that coordinates
> the various sub-components of your application.

Since the Refactoring Browser now makes it trivial to rename methods I'm
thinking about renaming #createSchematicWiring to something else for the
next release (keeping the call for backwards compatibility of course). Does
anyone have any suggestions for a more intention revealing name for the
replacement method?

Best Regards,

Andy Bower
Dolphin Support
http://www.object-arts.com
---
Are you trying too hard?
http://www.object-arts.com/Relax.htm
---

"Andy Bower" <[hidden email]> wrote in message
news:aiugnv$1710sm$[hidden email]...
[...]
> > #createSchematicWiring (which is -- for historical reasons -- *very*
badly
> > named) is the place where you would normally put the code that
coordinates
> > the various sub-components of your application.
>
> Since the Refactoring Browser now makes it trivial to rename methods I'm
> thinking about renaming #createSchematicWiring to something else for the
> next release (keeping the call for backwards compatibility of course).
Does
> anyone have any suggestions for a more intention revealing name for the
> replacement method?

Just to start what's sure to be a long thread: how about something like
#connectComponentEvents?

Don

"Chris Uppal" <[hidden email]> wrote in message news:<[hidden email]>...
The difference is there. Some version 4 code relaing to GUI didn't
work. So I looked at the sample code in version 5 -> there are indeed
differences when comparisons are made. I was able to compare the
differences but I guess I'm slow.

> There are *lots* of examples in the standard image.  If you look you'll see
> that they all follow a very similar sort of pattern.
Yes, the "if I'll stare at a screen long enough, it'll come to me"
trick would work. :-)

Anyway, I'm going into the Dolphin wiki and found that I'm not alone.
I'll dive in there and see if I can figure it out.

I noticed some source code is "not available". Is that a feature in
the Trial version or will it always be locked?

Also, the Lagoon deployment kit is not available in the Trial version
either. I guess I mistakenly thought it was (I'm using the
Professional edition on Windows 2000). I would have like to be able to
try it out. Oh well.

So far, Dolphin Smalltalk is looking good. I'm evaluating whether it
can replace VisualAge Smalltalk.

Our issues with VAST are as follows:
    1) VAST code is not clean which makes it harder for us to reuse
their library.
    2) It appears that IBM is not supporting VAST as it should. They
don't even want to market it anymore.
    3) RichText ActiveX control is a major issue for us. IBM was not
able to fix it for us so we were forced to re-run the application
after every session. I ran a "test" on Dolphin's RTF piece and it
didn't fail. The prospect of us writing an RTF piece in VAST is
daunting to us...... Looks like Dolphin takes care of that problem....
    4) VAST doesn't have user community support like Dolphin does....

I'm trying my best playing around with the code as quickly as I can to
see if Dolphin works for us in a short 30 day eval period. If Dolphin
works well, then I have to *convince* the management.

thanks,
Larry Trutter

Larry,

> I noticed some source code is "not available". Is that a feature in
> the Trial version or will it always be locked?

All the source is available in the full version.

> Also, the Lagoon deployment kit is not available in the Trial version
> either. I guess I mistakenly thought it was (I'm using the
> Professional edition on Windows 2000). I would have like to be able to
> try it out. Oh well.

The deployment wizard *is* available in the trial of the Professional
version. Perhaps what maybe confusing is the fact that the non-packaged
deployment mode has been removed (because it produced significantly larger
executables). You will need to use packaged deployment available from the
package context menu in the Package Browser.

http://www.object-arts.com/Lib/EducationCentre4/htm/deploymentstrategies.htm

In most cases "Packaged Class Based" deployment is to be preferred.

>     3) RichText ActiveX control is a major issue for us. IBM was not
> able to fix it for us so we were forced to re-run the application
> after every session. I ran a "test" on Dolphin's RTF piece and it
> didn't fail. The prospect of us writing an RTF piece in VAST is
> daunting to us...... Looks like Dolphin takes care of that problem....
>     4) VAST doesn't have user community support like Dolphin does....

The RTF control in Dolphin is purely based on the underlying Microsoft Rich
Edit control. In the past we have had a number of problems with the control
changing between different versions so that is something to watch out for.
Having said that, if it appears to pass your tests, all well and good.

Best Regards,

Andy Bower
Dolphin Support
http://www.object-arts.com
---
Are you trying too hard?
http://www.object-arts.com/Relax.htm
---

>                              Does
> anyone have any suggestions for a more intention revealing name for the
> replacement method?

#connectPresenter(s)
#linkPresenter(s)
#couplePresenter(s)

I would probably vote for the first as it fits in with the #connectModel
(and #connectView?) selector that performs a similar function.  Leaving it a
bit vague would also allow for the possibility of performing additional
tasks within the method, not just registering events.

Ian

> #connectPresenter(s)

I quite like that, but I think it'd have to be the plural, since the current
#createSchematicWiring isn't really parallel to connectModel (at least IMO).

Or how about #connectComponents, here following the lead of  the previously
existing #createComponents ?   (Mind you, it could be argued that
#createComponents is itself misnamed, since its really the place where you
create sub-presenters rather than full MVP sub-triads).

Or, trying a different tack altogether and trying to focus more on the more
abstract function/role of the method, rather than its typical
implementation:
    #setupRuntimeLogic ?
    #bindDynamicBehavior ?
I can't say really like either of those names, but maybe someone can think
of something good along similar lines.

Tricky innit ?

    -- chris

P.S.  Oh, oh, wait a minute... Hang on... Ok, here's an idea... How about
#createSchematicWiring2 ?

> Or how about #connectComponents, here following the lead of  the
previously
> existing #createComponents ?

Yes, I could easily live with that.  It describes what the method does
without being too specific and fits in well with the naming of
#createComponents.

Ian