Geeks With Blogs
Mike Kenyon Hoarked

Okay, recap.  We got the shell of the application up and running.  We’ve made two foundational modules to provide functionality to the business modules.  We’ve created a couple of business modules to allow people to browse the nominees and to allow them to vote.  We’ve refactored more times than I care to count.  We have also created possibly the ugliest application I’ve ever been associated with.

Left on the plate?  We’ve got the last major business module to write (that being the module that scores the Oscars when they’re on).   Next we’ve got a lot of styling to do.  Let me repeat that.  We’ve got a lot of styling to do.  Following that, we’re on to bells and whistles (like song clips, player photos and critical reviews).

Score Module Design

So, I’m down to the last module to create.  In some ways, it’s the most complex, in others, its the easiest.  I’m thinking in my mind that there are three major capabilities.  First, they’ve got to be able to pick a category.  God only knows what order they’re going to do the categories in, so I need to be able to pick in a random access fashion.  There are some general rules (best supporting actor tends to come first, best picture is always last, etc.).  Second, they need to be able to pick a winner.  The designer mind clicks in here and I’ve got a mental image of it being the 4 or 5 part split, but no matter how you cut it, at the moment its a list box.  Third, we want a leader-board, so that people can brag amid-game. 

Part of me says to keep things simple and make it as three separate views, part of me says life will be easier with one.  I’m going to take the latter approach till I find a reason to split it out.  Refactoring is life after all.

I don’t want the category selector to take up that much room, so I think I’ll plan initially on it being something like the selector control out of Kevin’s Bag of Tricks (which you should look up if you’re not familiar, a great tool to understand and learn WPF).  Barring that, I may decide that the carousel on a path is a better option, we’ll just have to see what the designer wants.  Either way, a ListBox is the correct choice for the actual control to use, everything else can be taken with styling.

For the leader-board, I don’t want a section model, the data should auto sort with the leaders on top.  I’m going to put it as an ItemsControl (it has multiple values and no selection model).

WPF Philosophy Aside

One of the things that I love best about WPF is the philosophy of developers designing by function and designers designing by appearance.  I’ve been an advocate of <strong/> and <em /> over <bold /> and <italic /> since the early, early days of the web.  I’ll admit my limitations and while I can make just about anything look the way the designer intended, coming up with that intent often alludes me.  As a developer, how it functions is more important to me than how it looks and WPF supports, embraces, nay insists on this separation.  If you don’t take it, it takes it for you through the use of styling.  The fact that I’m (as a developer) responsible for how something logicallly is laid out frees me from bit-twiddling to figure out why I’m 1-pixel off somewhere and let’s me concentrate on the important things.  It also means that I (as a designer) am responsible for the aesthetics and experiential behavior of the application and don’t have to worry about what and who gets called for what. 

I find myself using precious-few actual controls in actual user controls.   Typically, it’s ContentControl, HeaderedContentControl, ItemsControl, ListBox, Button, CheckBox and layout panels.  Just about everything else I can do styling.  Theoretically, I don’t even need panels, because I can use an ItemsControl and set the ItemsPanel for the control in the style … actually, that’s a pretty good idea.  I may refactor to do just that.

Flipping State

One of the things that I’ve noticed is that I tend to end up recreating views over and over.  This generally isn’t horrid.  There’s some gap in my activate vs. create logic that I’ve got to take care of.  In most cases, I’m displaying data out of a service and therefore don’t care, because the service itself is a singleton.  In this case, I don’t have a service (as a moral thing, I don’t create a service if one view is the only possible consumer) so I need to store some state that will will live between creations of the control (just in case).  I could store it in the database, but it’d be a couple fields and persisting the winners doesn’t really interest me.  It means I have to clean things out when I’m testing and I hate that.  So, I’ve got two real pieces of state.  First, who won each category.  Second, the leader-board.  The winner seems a perfect case for an attached property again.  This way, I can store data on someone else’s type without having it be (necessarily) readily apparent, public knowledge. For the leader-board, I’m going to store it in the Application object which has a hashtable for exactly this sort of situation.

For the leader board itself, I’m going to just make a derived ObservableCollection<Player>.  This gets me everything but sorting and I can throw an event handler to sort the list every time the player’s score changes.  So, how do I represent the scores?  I think that’s another great case for an attached property on the Player itself.

Without much problem at all, I got the system up.   Now onto styling.

See it here.

Posted on Saturday, February 14, 2009 9:56 AM | Back to top

Comments on this post: Creating a WPF Application With Prism v2 – The Final Frontier

No comments posted yet.
Your comment:
 (will show your gravatar)

Copyright © hoarked | Powered by: