[grand-rapids-pm-list] Model View Presenter

[Carlus Henry]

For those of you that did not come to the last Perl User Group meeting, you
missed a great presentation which prompted a wonderful discussion on the
Model-View-Presenter Pattern (MVP).  Primarily being a J2EE developer and
with many years of experience with the Struts Framework, I am very familiar
with the Model-View-Controller (MVC).  I was very interested, however, in
this MVP pattern.  This is mostly due to the thick client application
development that I have been doing lately.

During the meeting, a lot of questions were raised regarding this pattern,
and Jason Porrit was very patient with all of us (touche').  After the
meeting, I decided to do a little more investigation, and found the
following:

Martin Fowler Retires Model View Presenter Pattern

Yes.  Believe it or not, this pattern has been
retired<http://www.martinfowler.com/eaaDev/ModelViewPresenter.html>by
Martin Fowler.  Well, I don't know if retired is the correct 'r'-word.
Maybe it should say 'R'efactored instead.  He has split up the pattern into
the Supervising
Controller<http://www.martinfowler.com/eaaDev/SupervisingPresenter.html>and
the Passive
View <http://www.martinfowler.com/eaaDev/PassiveScreen.html>.  After reading
both of the patterns, they sound very similar in detail and in practice.  In
the Passive View you put all of the widget population logic into the
Presenter.  All logic is pushed on the Presenter including the population of
text fields or any other widgets available on the View.  In the Supervising
Controller, you push most of the logic onto the Presenter, but leave some of
the logic of populating widgets in the View.  Martin states:

"...the essence of a good *Supervising Controller* is to do as little as
possible. Let the view handle as much as possible and only step in when
there's more complex logic involved."

Atomic Object Presenter First
On a related note, Atomic Object <http://atomicobject.com/> also has their
own variation of the MVP Design pattern called Presenter First (PF).  After
reading an article from Better Software magazine (referenced from their PF
resources <http://atomicobject.com/pages/Presenter+First>), I find this
design pattern very attractive as well.  What most attracts me is the
concept of linking different PF triads in order to orchestrate behavior and
a process.  Please refer tot he Better Software article for more information
on this.

Overall, I owe a big thanks to Jason Porrit for inspiring me to learn more
about this design pattern.  I look forward to hearing him present in the
future.
-- 
Carlus Henry
SageTech L.L.C.
www.sagetech-llc.com | http://jdcarlflip.blogspot.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.pm.org/pipermail/grand-rapids-pm-list/attachments/20070705/bba8807c/attachment.html