Often times, the act of explaining a question out loud to another person involves a lot of complex and fleeting thought, we think at over 600 words per minute, and coalescing into sentences for the transmission from mental constructs to speech.  The thought process involved in this preparation for vocalization often restructures the problem in such a way that the question is answered in the asking.  An early mentor of mine called this effect “Talking to the bear”; he had a teddy bear on top of his monitor who served as a sounding board for his toughest issues, and later my issues as well. 

For a while, I’ve wanted to do some Reality Blogging.  Take a complex idea and a set of design goals, state them out loud, and slowly work towards a completed product or module.  Often times, I have presented an idea in, say, eight parts, because the idea was large enough to warrant breaking up for explanation.  The idea was fully baked before the first part was published.  The notion here, rather, is not to complete the idea but rather to work with both Visual Studio and Word open; to state design goals and see how they pan out later, to see how easy it was to refactor, to see a complex idea emerge out of nothing.

The Goal

The goal is to have an extensible, lightweight design surface and design-time environment for Silverlight.  As I have written about in the past (http://www.damonpayne.com/2007/04/24/Designer0.aspx) there are any number of neat reasons for which it would be useful to have  design time capabilities at runtime in applications.  My example application will be a Home Theater Layout application for Silverlight.  The vision is something like this:

So, I want this to be able to work in a manner we are familiar with: I drag things out of a toolbox onto a design surface, where I am allowed to drag and resize things.  When I select things I will be able to edit the selected item using a property grid.  I’ll want to support limited undo and be able to select multiple things to move around and so forth.

 In Windows forms, you can host the designer in your own application though it’s a lot of work. When the time came to make tradeoffs, the WPF designer “Cider” was not made hostable outside of Visual Studio.  Besides, there is no PropertyGrid for Silverlight, and no <<lots of other stuff>> for Silverlight, so this is really a big effort. 

Silver is Argentum in Latin, ergo its period table symbol is AG.  Ergo is also Latin, how fun.  Anyway, all the cool kids abbreviate Silverlight as “AG” and nothing sensible like “SL”.  The Latin word for “design” is more or less tela.  I dub thee, The ArGentum Tela project, or AGT for short. 

Design Goals

As Anders Heijlsberg said way back when he was famous for something called Delphi, it’s good to start out with some goals, it’s good to think about “how do I want people to use this?”  I have some design goals and functional requirements:

·         I want different aspects of the UI to function independent of each other

·         I want to be able to swap out different implementations for any aspects of the program that makes sense for

·         I want component to component communication to happen without components having references to each other

·         I want the building blocks of my program to feel like Serviced Components

·         I want to be able to serialize the results of my designer surface for later retrieval

·         I want a healthy # of common tasks accessible through the keyboard

·         I want this to work on the Mac.  I thought everyone was running Windows by now but apparently there are literally dozens of Mac users out there, so I should take their poor incomplete keyboards into account.

·         I want to package this as a reusable design-time library with a Reference Implementation – the home theater layout tool

·         I want to have as little code-behind/presenter as possible

I’ve been re-reading my GoF book, arguing with Dan almost every day, and reviewing the way the PRISM code looks.  I have some ideas about how I want to accomplish all of this.  As of now, my solution looks like this then:

·         DamonPayne.AGT

o   DamonPayne.HTLayout – the Silverlight sample project

o   HTLayoutWeb – a web test project for HTLayout

o   DamonPayne.AGT.IoC – how’s that for a name?  I’m going to pursue some inversion of control concepts for Silverlight, and that stuff will live in this assembly.

o   DamonPayne.AGT.Design – the code that makes the designer work will live here.

What’s next?

I’ve got Word open and Visual Studio open; it’s time to get started.  Where to begin?  In the next article we’ll start exploring some basic concepts for layouts and components.  Want to play along?  I’ll post the current source code at the end of each step.

 DamonPayne.AGT[0].zip (515.64 KB)