MVP Presenter skeleton code generator (view driven) released...

I just finished documenting my free Presenter Generator and have uploaded it
to my site : http://www.mitchellscientific.com/smalltalk/ .  This is alpha
code recommended for experienced users (for now).  I have been using it for
a few months, and it seems to behave well, but as usual: Use at your own
risk.  I finally forced my self to bite the bullet and document it. ;)

After you create a view with named sub views (textboxes, etc...) the
presenter generator will create some boilerplate presenter code for you.
Presenter instance variables will be created and a createComponents method
will be produced.  My code will handle sub classed presenters (it knows not
to recreate super class presenters).

This is very different from the code that Bill recently posted as his seems
to be programmatically (you write code to use it) driven, mine is view
driven (my package generates presenter code based on your view).  Each
approach has different uses.

Please give me feedback, and feel free to ask if you have any questions.

After all that documentation I am tired of writing for now. ;)  See the site
for more information.

Chris

Chris,

I haven't actually used it yet, but, my initial comment would be to simply
name presenters with the same name as the view.  The context usually makes
the distinction clear.  Just MHO.

Thanks!

Bill

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

Bill Schwab <[hidden email]> wrote in message
news:9hragb$f7sdh$[hidden email]...
> Chris,
>
> I haven't actually used it yet, but, my initial comment would be to simply
> name presenters with the same name as the view.  The context usually makes
> the distinction clear.  Just MHO.

Yes, that makes sense.  I had been thinking about whether it was really
necessary for me to have the 'Presenter' postfix.  A Presenter in a well
designed MVP triad probably would only have Presenters as its instance
variables so I may not need to keep them separate with the postfix.  The
only issue might be if some one incidentally decided to name a sub view
'model' as in that model of car.  Actually there could be a potential name
conflict like that in a Shell subclass, 'caption' comes to mind.  Are these
"far out" enough for me not to have to worry about?  I suppose I could do a
postfix only if there is a view name conflict with an instance variable
defined in a system  class (in the Dolphin package).

Thanks for the suggestion.
Chris

Chris,

> Yes, that makes sense.  I had been thinking about whether it was really
> necessary for me to have the 'Presenter' postfix.  A Presenter in a well
> designed MVP triad probably would only have Presenters as its instance
> variables so I may not need to keep them separate with the postfix.  The
> only issue might be if some one incidentally decided to name a sub view
> 'model' as in that model of car.  Actually there could be a potential name
> conflict like that in a Shell subclass, 'caption' comes to mind.  Are
these
> "far out" enough for me not to have to worry about?  I suppose I could do
a
> postfix only if there is a view name conflict with an instance variable
> defined in a system  class (in the Dolphin package).

Good point!  The conditional postfix is a nice way to avoid would-be
collisions; my preference would be to add it only when necessary to avoid a
collision.  Checking for such things is a good idea - not "far out" at all.
It sounds like you're on your way to making a nice tool.

Have a good one,

Bill

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