<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:times new roman, new york, times, serif;font-size:12pt"><div style="font-family: times new roman,new york,times,serif; font-size: 12pt;">That is a good question, but one I haven't worked through myself :)<br><br>I'll offer my thoughts anyway, and I think you're right that the Model should, in some way, own the transaction management. Here are two ideas that I think would keep things in line with the goals of Presenter First.<br><br><span style="font-weight: bold; text-decoration: underline;">Manage transactions in the Presenter through the Model.</span><br>Create methods on the Model that wrap your database transaction functions like (in perl) begin_work, commit, and rollback with more end-user oriented names like start_changes, save_changes, and abort_changes. Call those methods from the Presenter
like:<br><br>$model->start_changes();<br>$model->abort_changes() unless $model->save_new_username($username);<br>$model->abort_changes() unless $model->save_new_address($address);<br>$model->save_changes();<br><br>I know this is a trivial exmple, but I think that sort of logic does still sound reasonably like the story of the application from the user's perspective.<br><br><span style="font-weight: bold; text-decoration: underline;">Include all elements of a transaction in a single method.</span><br>In other words, don't spread transactions across multiple Model methods :) I think I would prefer to keep the Presenter in the dark about transactions and let the Model handle it. This also goes along with the "Finish what you start" idea from <a href="http://www.pragmaticprogrammer.com/ppbook/index.shtml">Dave Thomas' book The Pragmatic Programmer</a>, which I've found to be good advice. (I am willing to accept that there may be situations
where this doesn't make sense)<br><br><span style="font-weight: bold; text-decoration: underline;">Conclusion</span><br>As I said, I haven't worked through this myself so these are just unproven, untested ideas. This might be a good discussion to carry over to the XP West MI mailing list.<br><br>Hope that helps,<br>Jason Porritt<br><br><br><div style="font-family: times new roman,new york,times,serif; font-size: 12pt;">----- Original Message ----<br>From: Carlus Henry <carlushenry@sagetech-llc.com><br>To: grand-rapids-pm-list@pm.org<br>Sent: Thursday, July 12, 2007 10:06:51 AM<br>Subject: [grand-rapids-pm-list] Fwd: Model View Presenter<br><br>Meant to send this message to everyone.....What do you guys think?<br><br>Carlus<br><br>---------- Forwarded message ----------<br><span class="gmail_quote">From: <b class="gmail_sendername">Carlus Henry</b> <<a rel="nofollow" target="_blank" href="mailto:carlushenry@sagetech-llc.com">
carlushenry@sagetech-llc.com</a>><br>Date: Jul 12, 2007 10:06 AM<br>Subject: Re: [grand-rapids-pm-list] Model View Presenter<br>To: Jason Porritt <<a rel="nofollow" target="_blank" href="mailto:jasonmtu@yahoo.com">jasonmtu@yahoo.com</a>><br><br>
</span>Hey bud....<br><br>In your work with MVP, does when the presenter delegates to the model, who owns the transactions when doing commits? I am thinking that the model should own the commits....but what happens if the work that needs to be done is happening across two seperate model calls. When the second model operation fails it should roll back the first. But you are not able to do this unless the transaction is being controlled at the presenter level, which just feels awkward.
<br><br>What have you done?<br><br>Thanks<br><span class="sg">Carlus</span><div><span class="e" id="q_113bac03d6d17139_2"><br><br><div><span class="gmail_quote">On 7/11/07, <b class="gmail_sendername">Jason Porritt</b> <
<a rel="nofollow" target="_blank" href="mailto:jasonmtu@yahoo.com">jasonmtu@yahoo.com</a>> wrote:
</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><div style="font-family: times new roman,new york,times,serif; font-size: 12pt;">
<div style="font-family: times new roman,new york,times,serif; font-size: 12pt;">Thanks for the follow-up, Carlus. Atomic Object's Presenter First pattern is indeed very interesting, and I kind of wish we had jumped into that during the MVP discussion but we probably would have run out of time for the Perl testing section. Here are a few other links related to the meeting I meant to share with the group at the end:
<br><br><span style="font-weight: bold;">UI Design Patterns (Martin Fowler)</span><br> <a rel="nofollow" target="_blank" href="http://www.martinfowler.com/eaaDev/uiArchs.html">GUI Architectures
</a><br> <a rel="nofollow" target="_blank" href="http://www.martinfowler.com/articles/injection.html">Inversion of Control Containers and the Dependency Injection pattern</a><br>
<br><span style="font-weight: bold;">Perl
Testing</span><br> <a rel="nofollow" target="_blank" href="http://search.cpan.org/%7Emschwern/Test-Simple-0.70/lib/Test/More.pm%20">Test::More</a><br> <a rel="nofollow" target="_blank" href="http://search.cpan.org/%7Echromatic/Test-MockObject-1.08/lib/Test/MockObject.pm">
Test::MockObject</a><br><br>And to answer one of Carlus' other questions about IoC (Inversion of Control) containers for perl I did find two that look interesting:<br> <a rel="nofollow" target="_blank" href="http://search.cpan.org/%7Estevan/IOC-0.29/lib/IOC.pm">
IOC</a><br> <a rel="nofollow" target="_blank" href="http://search.cpan.org/%7Erhundt/Peco-1.0/lib/Peco/Container.pm">Peco::Container</a><br><br>My initial impression is that Peco::Container is a bit simpler than IOC. I haven't used either of them yet so I don't have much but the documentation to base that on. Neither of them do anything other than IoC, so a fair comparison may be between these two and Java's
<a rel="nofollow" target="_blank" href="http://www.picocontainer.org/">PicoContainer</a> instead of Spring which
is a full application framework in addition to an IoC container.<br><br>Thanks,<br>Jason Porritt<br><br><div style="font-family: times new roman,new york,times,serif; font-size: 12pt;"><div><span>
----- Original Message ----<br>From: Carlus Henry <<a rel="nofollow" target="_blank" href="mailto:carlushenry@sagetech-llc.com">carlushenry@sagetech-llc.com</a>><br>To: <a rel="nofollow" target="_blank" href="mailto:grand-rapids-pm-list@pm.org">
grand-rapids-pm-list@pm.org</a><br>Sent: Thursday, July 5, 2007 8:48:30 AM<br>Subject: [grand-rapids-pm-list] Model View Presenter<br><br>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.
<br><br>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:
<br><br><span style="font-weight: bold; text-decoration: underline;">Martin Fowler Retires Model View Presenter Pattern</span><br><br>Yes. Believe it or not, this <a rel="nofollow" target="_blank" href="http://www.martinfowler.com/eaaDev/ModelViewPresenter.html">
pattern has been retired</a>
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 <a rel="nofollow" target="_blank" href="http://www.martinfowler.com/eaaDev/SupervisingPresenter.html">
Supervising Controller</a> and the <a rel="nofollow" target="_blank" href="http://www.martinfowler.com/eaaDev/PassiveScreen.html">Passive View</a>. 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:
<br><br>"...the essence of a good <i>Supervising Controller</i> 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."<br><br><span style="font-weight: bold; text-decoration: underline;">Atomic Object Presenter First</span><br>On a related note, <a rel="nofollow" target="_blank" href="http://atomicobject.com/">
Atomic Object</a> 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 <a rel="nofollow" target="_blank" href="http://atomicobject.com/pages/Presenter+First">
PF resources</a>), 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.
<br><br>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.<br></span></div><span>-- <br>Carlus Henry<br>SageTech
L.L.C.<br><a rel="nofollow" target="_blank" href="http://www.sagetech-llc.com">
www.sagetech-llc.com</a> | <a rel="nofollow" target="_blank" href="http://jdcarlflip.blogspot.com/">
http://jdcarlflip.blogspot.com/</a>
</span><div>_______________________________________________<br>grand-rapids-pm-list mailing list<br><a rel="nofollow" target="_blank" href="mailto:grand-rapids-pm-list@pm.org">grand-rapids-pm-list@pm.org
</a><br><a rel="nofollow" target="_blank" href="http://mail.pm.org/mailman/listinfo/grand-rapids-pm-list">http://mail.pm.org/mailman/listinfo/grand-rapids-pm-list</a></div></div><span>
<br></span></div></div><span><br>
<hr size="1">Looking for a deal? <a rel="nofollow" target="_blank" href="http://us.rd.yahoo.com/evt=47094/*http://farechase.yahoo.com/;_ylc=X3oDMTFicDJoNDllBF9TAzk3NDA3NTg5BHBvcwMxMwRzZWMDZ3JvdXBzBHNsawNlbWFpbC1uY20-">
Find great prices on flights and hotels</a> with Yahoo! FareChase.</span></div><br>_______________________________________________<br>grand-rapids-pm-list mailing list<br><a rel="nofollow" target="_blank" href="mailto:grand-rapids-pm-list@pm.org">
grand-rapids-pm-list@pm.org</a><br><a rel="nofollow" target="_blank" href="http://mail.pm.org/mailman/listinfo/grand-rapids-pm-list">http://mail.pm.org/mailman/listinfo/grand-rapids-pm-list
</a><br></blockquote></div><br><br clear="all"><br>-- <br>Carlus Henry<br>SageTech L.L.C.<br><a rel="nofollow" target="_blank" href="http://www.sagetech-llc.com">www.sagetech-llc.com
</a> | <a rel="nofollow" target="_blank" href="http://jdcarlflip.blogspot.com/">http://jdcarlflip.blogspot.com/
</a>
</span></div><br clear="all"><br>-- <br>Carlus Henry<br>SageTech L.L.C.<br><a rel="nofollow" target="_blank" href="http://www.sagetech-llc.com">www.sagetech-llc.com</a> | <a rel="nofollow" target="_blank" href="http://jdcarlflip.blogspot.com/">http://jdcarlflip.blogspot.com/</a>
<div>_______________________________________________<br>grand-rapids-pm-list mailing list<br>grand-rapids-pm-list@pm.org<br><a target="_blank" href="http://mail.pm.org/mailman/listinfo/grand-rapids-pm-list">http://mail.pm.org/mailman/listinfo/grand-rapids-pm-list</a></div></div><br></div></div><br>
<hr size=1>No need to miss a message. <a href="http://us.rd.yahoo.com/evt=43910/*http://mobile.yahoo.com/mail
">Get email on-the-go </a><br>with Yahoo! Mail for Mobile. <a href="http://us.rd.yahoo.com/evt=43910/*http://mobile.yahoo.com/mail
">Get started.</a></body></html>