Subscribe
Contact Us
SearchPart 1 of Ron Jacobs' Presenter First Podcast
Posted on June 1st, 2007 by
Mike Karlesky
Ron Jacobs recently spent a morning with Dave Crosby & Scott Miller talking about Presenter First and recorded the conversation for his Podcast (read earlier post).
The video is available on ARCast.TV. The audio is available from ARCast Radio.
Jason Porritt Says:
June 1st, 2007 at 06:17 PMVery cool, guys. Keep up the good work! I've been toying around with some presenter-first ideas since having read your paper a few weeks ago, and I have to say I like it. The more functional approach of MVP seems to remove some of the awkwardness I've experience using MVC, or at least that's my impression thus far -- I haven't written anything more complex than a single triad yet using MVP. I'll be able to give it a better run in the next few weeks on a relatively simple Perl web app, though, and I'm very interested to see how it works out.
Allen Noakes Says:
June 4th, 2007 at 04:54 AMI've been using the CAB and MVP pattern for a while, but noticed in your video you do web development also. Have you tried the Presenter First Pattern with web development? Web is so different than Windows and we've been looking for a way to test the UI. Thanks! Great work!
Jason Porritt Says:
June 4th, 2007 at 01:25 PMAllen: If I'm getting the MVP pattern right, one of the main points is that the UI itself contains little or no logic and so has much less of a need to be included in your automated unit tests. You're right, though, about web development being a bit different than "Windows" development and maybe I can offer up a suggestions (being a web developer myself). I have been using a piece of software from http://openqa.org/ called Selenium to automate acceptance tests for various web applications. Selenium will let you automate a web browser (IE or Firefox) and interact with you applications exactly as the end user would. This is especially handy when you want to test anything involving javascript. These tests usually are written after the application has been rolled out because they do usually have to be refactored when the HTML changes. I recommend checking out the website for more information. Really, though, those tests are of secondary importance to me because the most important logic does not reside in the HTML-generating code (templates) or the javascript. The really important stuff has been pulled out into modules that are easy to test, which is something I like about MVP as described by Dave and Scott in the video.
Zach Dennis Says:
June 6th, 2007 at 07:10 PMAllen - A few of us have been working on a PF based approach to web development using Ruby On Rails called Model Conductor Controller (MCC). The project hasn't released any files yet, but the SVN is open and there are working examples. Check it out at http://rubyforge.org/projects/mcc/ MCC focuses on extracting a new triplet from the standard MVC triplet that most web-based MVC frameworks have built-in. Rails itself has divided a standard web application into a database/domain model, a controller which handles routing URLs and responding to actions and a view which is composed of templates combined of ruby code and HTML. One of the issues we've commonly seen is that the controller and the view are very tightly coupled. Because the controller also is in charge of managing incoming requests with outgoing responses there seems to be good chance that a large amount of domain logic will end up happening in the controller. Another issue we've seen is that the database model can only successfully live a double-life as a domain model for a short period of time. Once domain logic is introduced which requires the use of multiple database models for a particular feature or action it is time to create a real domain model. MCC strives to make this a clean separation. MCC uses the conductor to act as the glue, similar as the presenter in PF. The conductor manages events from controllers and from domain models. Because of the separation between the model, conductor and controller you're able to start driving your features from your conductor and then implementing the model and the controllers as you need to. This seems to help a lot in testing because database calls will only be made from your domain models and there is no longer a chance of those same calls being made in your controller. One of my hopes for something like MCC is that views get back to being more basic. In Rails there are helpers built-in to the framework which digs into the depths of the database models to provide fancy automatic form creation in HTML. There are times where this is helpful, but more often then not people end up throwing a lot of code into the view itself to achieve the same effect. MCC encourages a best practices approach which discourages this kind of complex view logic to be placed in the view. One limitation that MCC still has (in which I believe all web apps inherently have) is the lack of view testability. MCC simplifies the design and separates responsibilities of the application, but it doesn't aide in view testing. There are lots of smart people working on solving this. Tools like selenium will hopefully fill the gap. As of right now MCC is a idea in motion. Hopefully it will help spark better ideas for how to achieve better ways to develop web apps.
Ralf Kretzschmar Says:
June 6th, 2007 at 08:46 PMHi guys, I was familar with the MVC/MVP style of doing things but to add the process perspective to it is just great. That really ties things together nicely. Congratulation. I haven't heard all of the podcasts but what I like most, is that you treat a call back to the user (for example to get a filename) like a call to a data store for retrieveing some data. I've been calling that "THE USER AS AS SERVICE" for a while and I had a hard time to get people to understand what I meant, so I almost gave up regarding that concept. Hearing you talk about that in the interview and writing about it in your papers confirmed my believe that there is a such thing. Because if you look at it in this way you can just mock your use out for doing unit tests (unfortuanatly that is not possible when you are writing user stories, ;-)) which in turn gives a completely new meaning to the term "User Interface": Maybe there are situations where the user interface is the interface that the model uses to get something from the user? Anyway I'm looking forward to the third part of your interview. I would be especially interested in your way of handling really complex views (Tree Views, Editable Lists, ...) maybe I'll find something in your examples. Keep on with your great work and a special thanks for sharing your insights! Ralf
Drew Colthorp Says:
June 7th, 2007 at 04:03 AMHi Allen, Zach Dennis and I have been working on a Rails plugin over the past couple of weeks that attempts to make MVP convenient for web development. Our approach starts with the Rails MVC web architecture and adds functionality to enable MVP. Our plugin is called ModelConductorController. "model", "view", and "presenter" all have specific meanings to a rails developer (Presenters aren't built-in, they're a technique developed by Jay Fields: http://blog.jayfields.com/2007/03/rails-presenter-pattern.html), so we opted to call the presenter "conductor" and the view, in the MVP sense, is just the Rails controller object with some mixed in functionality. When a user hits a url in rails, an action – a method defined in the controller – is called. Rails controllers are tightly tied to HTML templates (Rails 'views') and similarly contain a number of hashes, corresponding to the user's session and cookies, that can be described as state. Our plugin includes some mixins and a simple dependency-injection mechanism that make it easy to pull data related code into the model and business logic into the conductor, leaving the controller left as a simple view. With MCC, controller actions contain no logic, but simply fire an event listened to by the conductor. The conductor is similar to pretty much any presenter you've ever written. It listens to events and processes in response to the firing of those events. The model abstracts database, session, and cookie access for the presenter. The controller, in addition to the user-accessible actions which are exposed on the web as URLs, also contains a number of methods which can only be executed within ruby. These methods are called by the presenter to render output, modify headers, etc. The flow then, looks usually looks something like this. When a user hits a url, the model and conductor (as well as auxiliary objects) are constructed by the dependency-injection mechanism. The controller then fires an event corresponding to the action which the user accessed. The conductor listens to this event, calls some methods on the model, and then calls a method on the controller to render a specific html template, which may parameterized by the data returned by the model methods. There'll be a blog post about this soon, but note that the plugin hasn't been officially released, hasn't been used in production, and is still changing substantially. You can check out the plugin from rubyforge with: svn checkout svn://rubyforge.org/var/svn/mcc/trunk Included with the plugin is a modified version of the Depot ecommerce application which comes with the rails book. The admin and store controllers have been converted to use MCC and tested. Drew Colthorp
Mike Karlesky Says:
June 22nd, 2007 at 07:47 AMRalf, Yes! In fact, we treat dialog boxes exactly as you've hypothesized. Asking the user a question or querying him/her for information is a call to the Model that in turn displays some form of DialogShower. Since dialog boxes often have no connection to a given window other than in terms of focus or modality, this works very well. The DialogShower is given a handle to the appropriate parent window and then displays the appropriate dialog and collects information from the user. That information flows through the Model as any other query for information to the system and is processed by the logic of the Model. Complex interfaces are simply a composition of simpler triads. A single, complicated window may be composed of half a dozen or more simpler MVP triads (coordination occurs by tying together the individual Models). Handling complex widgets like trees is not generally difficult if they are part of the widget toolkit. We assume that these widgets work as advertised and simply wrap the needed UI functionality in a View. If a widget in question uses a separate data structure to do its job or is particularly complex, we may manage the widget's data structure in the Model or supplement the View with a helper Adapter (that can be unit tested). If we construct custom widgets we create a triad to segregates UI calls from data/logic. A wrapper around the widget's Model will expose certain functions to the outside world (these functions would ultimately be wrapped in a View by a triad utilizing the new widget).
Marvin Bellamy Says:
September 27th, 2007 at 02:50 PMI'm also starting to experiment with PF, but I'm hung up on adapters and custom widgets. I'm creating an interactive graph from model data, but the nature of the adapter-view relationship is still a question mark. Assuming that I create a triad for the custom widget, what does the view interface look like? Does it take an image object (of the graph) created in the adapter or does the custom widget view accept more primitive data like coordinates for drawing lines?
Sheila Says:
November 9th, 2007 at 06:41 AMDo you have any .NET examples of the Presenter First pattern that utilize adapters and the DialogShower interface?
Boban Says:
January 21st, 2008 at 05:46 AMFirst of all, I want to congratulate you guys for good work. In your example (C#) I've notice that presenter, view and model are created and initialized inside main entry function. Now, my question is where would be the best place to create and initialize presenter, view and model in ASP.NET application? I came across on several examples that do this initialization inside page code behind. Thanks.
Mike Karlesky Says:
February 2nd, 2008 at 12:06 PMBoban, Take a look at the Spring.NET framework. This framework offers far more features than we use. However, we've successfully used Spring.NET to simplify and make testable the task of instantiating objects (MVP triads) and "wiring" them together to build a Presenter First application. We centralize instantiation in a single place using dependency injection. We've not done work in ASP.NET, but this tool and basic object construction technique should work fine for you in implementing a PF application. http://www.springframework.net http://en.wikipedia.org/wiki/Dependency_injection