Choose your own adventure! Where does "Build your own CAB" go next?

Everyone,

The “Build your own CAB” series has enjoyed a very warm reception and I thank you all for the compliments I’ve received over the last couple weeks.  Before I go on much farther with the series, I want to open the “story” prioritization up to you all to make sure we talk about the things you care most about before I run out of steam on this one.  I’m finishing up the Passive View pattern right after this, but after that I’ll leave it up to you.

Here are the topics I have in mind:

  • Assigning responsibilities to the Model View Presenter triad
  • Patterns of View/Controller communication
  • Presentation Model – a different take on Humble View’s
  • Synchronization issues with the backend
  • What are the options for the Model?  (short)
  • Using the Notification Pattern.  Performing input validation in the Domain Model and connecting these errors to the screen elements
  • Pluggability — tricks and examples for wiring together UI components with StructureMap
  • Event Aggregator — coordinating events to disparate screen elements in a loosely coupled manner
  • Subcutaneous Testing
  • MicroController, a recipe for better screen element synchronization.  I’ve written a partial replacement for data binding that bakes in declarative screen element behavior and testability
  • Building an Application Shell — I’ve got 3-4 different examples of building an ApplicationShell/ApplicationController to handle navigation and screen coordination
  • Driving WinForms through Fitnesse/StoryTeller tests.  What’s worked for me, and what’s bombed.
  • Applying NUnitForms (I’m an admin on NUnitForms, and it never gets the attention it deserves)

If you’ve got a preference, just let me know.

 

Thanks,

Jeremy

About Jeremy Miller

Jeremy is the Chief Software Architect at Dovetail Software, the coolest ISV in Austin. Jeremy began his IT career writing "Shadow IT" applications to automate his engineering documentation, then wandered into software development because it looked like more fun. Jeremy is the author of the open source StructureMap tool for Dependency Injection with .Net, StoryTeller for supercharged acceptance testing in .Net, and one of the principal developers behind FubuMVC. Jeremy's thoughts on all things software can be found at The Shade Tree Developer at http://codebetter.com/jeremymiller.
This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • todd

    please, please, please
    * Driving WinForms through Fitnesse/StoryTeller tests. What’s worked for me, and what’s bombed.
    * Applying NUnitForms (I’m an admin on NUnitForms, and it never gets the attention it deserves)

  • Tobi

    1. Pluggability — tricks and examples for wiring together UI components with StructureMap
    2. Presentation Model – a different take on Humble View’s
    3. Using the Notification Pattern. Performing input validation in the Domain Model and connecting these errors to the screen elements
    4. Building an Application Shell — I’ve got 3-4 different examples of building an ApplicationShell/ApplicationController to handle navigation and screen coordination
    5. Patterns of View/Controller communication
    6. What are the options for the Model? (short)
    7. MicroController, a recipe for better screen element synchronization. I’ve written a partial replacement for data binding that bakes in declarative screen element behavior and testability
    8. Event Aggregator — coordinating events to disparate screen elements in a loosely coupled manner
    9. Driving WinForms through Fitnesse/StoryTeller tests. What’s worked for me, and what’s bombed.
    10. Synchronization issues with the backend

  • Oliver

    1. Application Shell

    2. Notification Pattern

    3. Pluggability

    i wouldn’t mind if you would also show off the rest of the things.
    your blog is super interesting, keep it up.

  • Dan

    1. Patterns of View/Controller communication
    2. Assigning responsibilities to the Model View Presenter triad
    3. Synchronization issues with the backend
    4. Using the Notification Pattern.

  • James Maul

    My top preferences would be:

    1 – Presentation Model – a different take on Humble View’s
    2 – Building an Application Shell — I’ve got 3-4 different examples of building an ApplicationShell/ApplicationController to handle navigation and screen coordination
    3 – Assigning responsibilities to the Model View Presenter triad
    4 – Driving WinForms through Fitnesse/StoryTeller tests. What’s worked for me, and what’s bombed.
    5 – MicroController, a recipe for better screen element synchronization. I’ve written a partial replacement for data binding that bakes in declarative screen element behavior and testability
    6 – Subcutaneous Testing

    And congrats for this excellent series!I can’t wait for the next episodes!

  • http://dmihalik.com Dustin

    Here are my top 4. But I’d like to see some of the other ones, too. Put them all in a book and I’d totally buy it.

    1. Building an Application Shell
    2. Pluggability
    3. MicroController
    4. Applying NUnitForms

    The first three I would really like to see, and for the last one I agree that NUnitForms deserves some more attention.

  • http://www.JeremyJarrell.com Jeremy

    They all sound good but I would specifically like to see:

    1) Driving WinForms through Fitnesse/StoryTeller tests. What’s worked for me, and what’s bombed.
    2) Applying NUnitForms.

    I work primarily in WinForms and often result to striving for a passive view as I’ve all but given up on unit testing them. So any help on how to do that would be a benefit.

  • http://blogs.ugidotnet.org Emanuele

    Here’s mine:
    1) Building an Application Shell — I’ve got 3-4 different examples of building an ApplicationShell/ApplicationController to handle navigation and screen coordination
    2) Assigning responsibilities to the Model View Presenter triad
    3) Synchronization issues with the backend
    4) Using the Notification Pattern. Performing input validation in the Domain Model and connecting these errors to the screen elements
    5) MicroController, a recipe for better screen element synchronization. I’ve written a partial replacement for data binding that bakes in declarative screen element behavior and testability

    Others…
    Thanks!!!!

  • Ross Neilson

    Jeremy,

    My preferred running list would be

    Synchronization issues with the backend
    Using the Notification Pattern
    Building an Application Shell
    Driving WinForms through Fitnesse/StoryTeller tests
    Applying NUnitForms

    Thanks very much for an excellent series of posts. It good to see readers being given practical advice and examples on how to improve the structure of their applications.

  • Johan

    Hi Jeremy,

    My preferences: Just show them all :-)

  • Mark

    Here are my preferences

    1. Pluggability — tricks and examples for wiring together UI components with StructureMap
    2. Event Aggregator — coordinating events to disparate screen elements in a loosely coupled manner
    3. MicroController, a recipe for better screen element synchronization. I’ve written a partial replacement for data binding that bakes in declarative screen element behavior and testability
    4. Driving WinForms through Fitnesse/StoryTeller tests. What’s worked for me, and what’s bombed.
    5. Applying NUnitForms (I’m an admin on NUnitForms, and it never gets the attention it deserves)

  • Afif

    A very hard list to choose from nevertheless, here are my preferences (in the given order)
    1. Using the Notification Pattern. Performing input validation in the Domain Model and connecting these errors to the screen elements
    2. Pluggability — tricks and examples for wiring together UI components with StructureMap.
    3. Synchronization issues with the backend
    4. Applying NUnitForms (I’m an admin on NUnitForms, and it never gets the attention it deserves).
    5. Driving WinForms through Fitnesse/StoryTeller tests. What’s worked for me, and what’s bombed.
    6. Assigning responsibilities to the Model View Presenter triad.

    BTW, fantastic series, keep em coming.

    - Afif