Have you seen the circus gag where clown after clown emerges from the smallest car one could possibly image? Well, this week on Herding Code, the guys attempt that very same trick! Listen in as Jeremy Miller, Ward Bell, Rob Eisenberg and Glenn Block (that’s right, four guests!) join the cast and talk Presentation Patterns. This conversation started earlier this week on Twitter and it is shows no sign of slowing down. Join us this week and next for an enlightening and exhaustive discussion about Views and Models and ViewModels and everything in between.
- Kevin asks the four guests to introduce themselves and then turns the podcast up to 11.
- Jeremy kicks off the conversation with the “View First vs ViewModel First” discussion. Jeremy talks about Views, ViewModels, Presenters, Behaviors, Implementation Detail, Separated Presentation, Passive View, iView Interface, Screen Activation, and User Controls… In summary, he’s pro-ViewModel or Presenter first.
- Ward asks if anyone wishes to defend the View First position.
- Rob shares that he tends to create his View and Presenter at the same time (although he’s mostly a Model kind of guy.) Rob also calls out that he does a lot of prototyping in his workflow.
- Ward talks about where his development always starts – sketching out the UI with his clients. The ViewModel is ultimately developed to support the interaction discovered in sketching.
- Rob agrees. Talks more about prototyping first, gathering requirements, user feedback, workflow, architecture and conventions.
- Jeremy considers application navigation, behavioral aspects of screens and the contract for view.
- Glenn calls out the difference between Balsamiq mockups and screens which are maintained by a designer in Blend. Which approach best supports the tooling experience, maintainability, and testability? Glenn references Jonas Follesoe and how his designer girlfriend couldn’t function unless he defined the View first. Glenn initiates conversations about Service Locators.
- Jeremy questions whether one needs that level of detail. Do you need to fake in a service locator for your designer experience or are there alternatives?
- Glenn stresses that we must think about the designer (albeit there aren’t many right now), consider tradeoffs with varying approaches, talks about Prism and Patterns and Practices experiences, and tooling – particularly Blend.
- Rob talks about providing simple conventions which are taught to designers in lieu of using an inversion of control containers like Windsor.
- Glenn asks what the designer would see inside of Blend in this case and Rob isn’t aware of any limitations with this approach. Is this an issue of designer not having sample data to work with?
- Jon shares his experience at Vertigo – applications favor design and tooling, applications don’t have complex business rules, applications are Blendable.
- Jeremy appreciates that appearance may be the most challenging aspect of some applications. In this case, maybe View First is the most appropriate approach but having Blend driving workflow is a case of the tail wagging the dog. We need to consider the line of business applications and in that case ViewModel or Presenter must come first.
- Glenn notes that the View being created first as part of instantiation does not correlate to whether the ViewModel drives behavior from that point on. View First is at the point of activation. Whether the view is injected into ViewModel or the ViewModel get set into the View, the ViewModel is the guy which is in control.
- Jeremy explains the Screen Activation pattern and some fairly complex scenarios where logic is executed before the view is activated.
- Ward states that he is not a fan of the view determining the ViewModel or the ViewModel selecting the View and prompts Jeremy by asking if a factory could pull the right pieces together and sequence them.
- Jeremy takes Ward’s queue and talks about the Screen Activator acting as the gatekeeper which puts screens together. Jeremy reference the Caliburn approach.
- Rob clarifies the Caliburn ViewModels hierarchy and the use of screen activators and the composite pattern.
- Glenn talks a bit about complexity, CAB, debugging hierarchies, event aggregators and messaging.
- Jeremy calls out the benefit of using a composite pattern on a dashboard type application where a part of the screen may act as an application itself but an event aggregator would be best of cross-piece communication.
- Rob notes that communication in Caliburn is local – it is parent to child or child to parent and this approach can really simplify development.
- Jon and Rob discuss the approach of simply navigating between two tabs. Would you use event aggregation, publishing event, commanding or what?
- Jeremy gives detail to the Screen Conductor role and pattern and Rob stresses the value of methods such as Initialize, Activate, Deactivate, Shutdown and CanShutdown. Jeremy and Glenn walk through an example.
- Glenn, Rob and Jeremy consider roles and patterns and if they vary from application to application. Is there an established best practice? Jeremy believes roles seem to be consistent but implementation changes from project to project.
- Ward wraps up Part 1 stating that he agrees with the idea of like roles but not ready to lock into any implementation. He suggests we call out the actors and see how it plays…
- This conversation just won’t end. Be sure to tune in next week for Part 2.
Show Links:
- Jeremy Miller, Dovetail Software
- Ward Bell, IdeaBlade
- Rob Eisenberg, Caliburn, Blue Spire
- Glenn Block, Microsoft
- Expression SketchFlow
- Expression Blend
- Balsamiq Mockups
- Jonas Follesoe
- NDC2009 – Norwegian Developers Conference
- Windsor
- Pattern and Practices
- Build Your Own CAB Series by Jeremy Miller
Download / Listen:
[audio://herdingcode.com/wp-content/uploads/HerdingCode-0057-Presentation-Patterns-with-Jeremy-Miller-Ward-Bell-Rob-Eisenberg-and-Glenn-Block-Part-1.mp3]Show notes compiled by Ben Griswold. Thanks!
