This project is read-only.


This is part 1 in a series of demos to accompany an East Bay .Net User's Group project. While the User's Group project takes a "software-as-service" approach, our series will focus primarily on the presentation layer, applying WPF to a set of non-trivial interface requirements, while paying special attention to the need for clean, maintainable, extensible code. The project consists of an OrderEntry application, used to generate and track walk-in and phone-in customer orders, with a separate OrderMonitor application to display open pizza orders to the kitchen staff. We are NOT trying to suggest that this particular UI (or the use of WPF, for that matter), would represent an appropriate solution for a similar set of real-world business requirements, but it enables us to discuss many real-world project concerns while exercising a broad range of WPF features.
  • PizzaManiac 1: Simplistic WPF layout to support basic application structure and behavior
  • PizzaManiac 2 : Realistic feature set, real-time WCF communications, and some UI customization
  • PizzaManiac 3 : Significant increase in complexity, to support multiple product types
  • PizzaManiac 4 : Robust communications and data management, .Net 3.5 updates, and a more polished UI

In this initial demo, we are purposely tring to keep things simple, using a subset of key WPF features to generate functional UI shells for our two client applications. Future iterations will add a much more polished appearance, support real-time WCF communication between the two client applications, and greatly extend the supported feature set -- at the cost of a significant jump in code (and markup) complexity. For demo purposes, I've tried to optimize the layout of the UI to enable displaying the two clients side-by-side at the most common projector resolution of 1024x768.

The OrderEntry screen displays a list of Orders and their state. The underlying implementation uses a DataTemplate to define how an Order should be displayed, with custom ValueConverters to interpret binding information. Definitions of colors and styles are kept separate from the markup that uses them, in ResourceDictionaries -- a habit that's critical to keeping the markup easy to understand and maintain as the application grows.


Adding or editing an Order triggers an animation which makes it appear as if the selected Order item is expanding or collapsing to expose or hide Order information for editing. WPF makes it trivial to support edit operations by simply setting the DataContext of the edit view to refer to the currently-selected Order, but the common requirement to be able to CANCEL edit operations requires some trickery, and we use simple "Clone" methods on the underlying business objects to avoid polluting the UI with ugly code to track edit changes. The UI is implemented as a set of nested UserControl-derived views, and this encapsulation of markup and supporting code helps control code volume and complexity.


This crude initial shell for our KitchenMonitor UI leverages WPF's support for control customization by replacing the standard "Stacked" view of list elements, with a "Wrapped" view. Selecting a list item triggers a style change in the underlying DataTemplate, exposing a "Close" button which will cause the item to be removed from the list and, in our next demo, notifying the OrderEntry client that our Pizza is ready. Other enhancements to this UI will include display of standard options ("Xtra Cheese", "Deep Dish"), listing explicit ingredients for Custom pizzas, and using color to warn that we're in danger of missing our 30-minute delivery guarantee...


Alternative Interpretations

There are obviously many other possible approaches to supporting the required feature set with a WPF layout. The "Outlook" style, left-side selection, right-side detail view is a likely alternative for the OrderEntry application, that one of the other User Group members might want to try.


Real-world "Point Of Sale" solutions, used at franchises like Baja Fresh, TGI Friday's, and elsewhere (check out the Pizza Hut case study, from Micros), rely on a limited set of colors, and little animation, but have the same "order entry - kitchen display" dual application architecture, supporting the same basic set of features.


A Note About our Application Title: I can't remember which member of the Windows developer community suggested Microsoft keep their pizza-related demo names consistent with the naming conventions they apply to their release products, but I thought it was funny, and I'm hoping someone can remind me who to properly credit for the "MeatAndCheeseDisc Management Server" product name knockoff.

Other projects by Andy L.

Last edited Oct 14, 2008 at 4:39 AM by AndyL2, version 60