Introduction
Signum Windows is the assembly that will help make being more productive building a
WPF client application. There are three main design principles that we follow in order to make Signum Framework:
- Taking profit of Signum Entities: Building a UI with Signum Windows is faster than writing it with WPF alone, not because Microsoft guys have been too vague to do it right, but because we have a solider basement: Signum.Entities. We enforce every entity to have ID and ToStr, and how the relationships, and the collections have to be implemented. We also have a consistent model for validation and change tracking, and we know how to deal with lazy objects and enums. All these requirements make it easier for us to build something like Signum Windows.
- Being a good WPF citizen: WPF is a nice product, it has very deep concepts that have been missing in any previous frameworks (like declarative XAML synthax, Attached Properties, Items Control, and a very powerful Databinding technology). We didn't want to reinvent the wheel, moving you to some proprietary DSL, control or environment that makes you more productive at the cost of loosing control. Instead we used XAML power to create clean an concise syntax for the common business applications requirements, without loosing any expressiveness that empowers your creativity when needed.
- Fill WPF Gaps: WPF has archived excellent results in defining the foundations for windows presentation development, but it has been poor in the final polishing for building real life applications. There is no DateTimePicker control, no ColorPiker, neither easy auto-completion in TextBox. We tried to fill these gaps to make it usable until Microsoft comes up with an official alternative.
Signum.Windows Map
Here you have a basic map for Signum.Windows main classes:
The main task when using Signum Windows to build your User Interface, is creating the WPF control that defines how an entity (or graph of entities) is going to be displayed.
Your entities' controls are usually composed of
EntityLine, ValueLine, EntityCombo, and so on... that play well with the attached properties defined in
Common class, but you are free to use
other controls defined in Signum Windows or any
standard WPF control to compose it.
Also, these controls you create, will be used to view and edit scenarios, and can be inserted in a
both NormalWindow and AdminWindow. Any of these two windows provide a
useful panel at the left side for things like QuickLinks and Notes.
Finally there are some static classes that are internally used by Entity Controls, but you are free to use them as well:
- Navigator: Handles all the navigations for Viewing an entity, Admin some type of entities all at once, of Find an entity using a search window.
- Constructor: Sometimes building an entity has to be done differently when you are on the client side of the application. Constructor static class lets you define how entities should be created in this situation.
- Server: Server is the equivalent of Database from the client side. This static class lets you communicate with the server using general purpose methods for saving or retriving entities, or nice generic overloads for custom client business logic.
Other User Interface Frameworks (Advanced Topic)
These general purpose methods defined in
IBaseServer are the key difference of Signum Windows. Having an unified way to save and retrieve entities puts us in a better position to make a UI framework for business applications. Let's see the two main strategies used by other UI frameworks (Windows and Web):
Generate Code
One solution is to generate the user interface code from your data model (tables or entities). Code generations save you from writing the code, not from maintaining it. In fact, code needs to be automatically generated when it takes too much code for something to work, and this happens when the framework is not expressive enough (high redundancy).
There are situations where generating code is a good idea, though. If only the source is allowed to be modified (not the product), code generation is OK. This is not usually the case of User Interface, where the entity (source) will change, and also the user interface (product) has to be customized to make it more user-friendly.
Ruby on Rails follows this approach to generate the ActiveRecords and also the html of your website.
Dynamic Generation
The second main strategy is to automatically generate the user interface at runtime, using some kind of
type introspection (reflection). This completely saves us from writing and maintaining user interface code, but you have to agree with the results because changing it is hard.
Any change you want to make have to be defined as an exception of the dynamic generator default behaviour, so you are limited to the expressiveness of the available exceptions provided by this runtime. Also, because this information can't be specified in the source itself (decoupling user interfaces and entities), these exceptions can get quite messy.
Django Admin interface or
ASP.Net Dynamic Data uses this approach.
Our solution
Dynamic generation is fast, but not flexible enough for a general purpose UI framework. Generating code, on the other hand, makes writing code faster, but creates a nightmare if you have to modify it.
The only way to solve this, in our opinion, is to work at the right level of abstraction: Being able to specify the common things you find in business user interfaces more easily, like collections, value fields, etc...
The obvious way of doing it is to build your own User Interfaces Domain Specific Language. We had our own custom Xml format for defining user interfaces in WinForms some time ago. The problem with this approach is that you end up being as expressive as the DSL allows you to be.
Now, with Xaml available, there's no point in writing our own Xml format any more. Just writing a set of convenient controls and attached properties that make your Xaml look like a DSL for business application is enough. The good news is that you are still writing code inside of a very powerful UI environment (WPF) so you are still able to integrate Signum.Windows code with any other WPF code seamlessly.
We archive productiveness by having
convinient controls and a
solid basement that allows us to work at the right level of abstraction. Actually, there's not a lot of code in Signum.Windows compared to its' benefits. The important thing about Signum.Windows is not that it's already programmed and ready for you to use, no way! The important thing is that, once you have an standardized way of dealing with your entities, it's possible (and easy) to build a visualization framework that increases your productivity without having to invent anything extremely clever. In fact, we think that we could take advantage of the solid base provided by Signum.Entities in any other environment, like
Web (coming soon) or the now legacy WinForms platform.