Now that we’ve spent the last five articles spelunking into the glorious underbelly of the Dynamic Data runtime, and seeing what it offers, we need to begin investigating how to allow a MetaModel to “light up” our UI. Everything that we’ve seen up to this point is completely agnostic to any specific presentation framework. Dynamic Data (as a runtime) simply provides the infrastructure for translating a data model, complete with metadata and validation, into a higher level model (MetaModel) that has the potential to be interpreted by an application.
Within the .NET 3.5 SP1 release, the initial consumer of Dynamic Data (and the newly introduced data annotations) was ASP.NET WebForms. This means that if you’re developing a data-driven web application, and your weapon of choice is WebForms, then you just happen to be in luck. Work is already underway to introduce some of Dynamic Data’s behavior into ASP.NET MVC that is appropriate to its style of development, and you can expect to see additional UI frameworks taking advantage of its semantics and data annotations as well in the near future.
So, the question becomes: now that I’ve got my data model, and I registered it with a MetaModel, how can I begin taking advantage of it within a WebForms application? Since it is the MetaModel that contains all of the metadata and validation, as well as the shape of our underlying data model, reason would lead us to believe that we’d need some type of server-control that was aware of a MetaModel and is ready to allow it to affect its behavior.
If you were to begin developing a data-centric WebForms application today, what are your options as far as server controls go? There’s actually a pretty rich arsenal of controls that can get you up and running pretty quickly, without having to sacrifice functionality…
Data Controls:
|
Data Sources:
|
All of those controls are awesome in their own way but they don’t exactly help us in our current endeavor. Not a single one of them has a clue what a MetaModel is or is really conscious of what being “data-driven” means. They support the notion of metadata and validation, but we have to explicitly define that information, instead of them deriving it from our data model.
While these controls lack some of the functionality we require we certainly don’t want to have to introduce a whole new suite of controls that we have to learn just to enable data-centric applications. What would be ideal is if we could extend or enhance the functionality that these controls already have to make them more fully-featured and MetaModel-aware. Luckily this is exactly what Dynamic Data provides, in the form of the following controls:
- DynamicField
- DynamicControl
- DynamicControlParameter
- DynamicQueryStringParameter
- DynamicDataManager
- DynamicValidator
- FieldTemplateUserControl
While these new controls provide a lot of the functionality we’ll need, there is still one piece left to complete our little journey towards data-driven utopia: field-level templates. Since our focus is on the data in our application and the metadata that is associated with that data, a lot of times we might want to allow the presentation framework to determine how to render portions of our data automatically based on the structure of the data model, or better yet, the MetaModel.
These field-level templates could define the UI desired to display data of different types. This would allow us to determine how we wanted numbers, string, dates, etc. to look, in a single location, and have those templates leveraged throughout our entire application. Regardless whether we were creating tabular or form-based data entry forms, we could take advantage of the same templates, providing a consistent look and feel that is completely driven from our data model.
The FieldTemplateUserControl is what makes this functionality possible, and will be the focus of the next article. We’ll cover how it can be used to define custom field templates, as well as what field templates are provided out-of-the-box by Dynamic Data. Finally, we’ll cover how to wire-up your defined field templates to actually be used with your created MetaModel, effectively completing the field-level templating story (which is one of two possible scenarios provided by Dynamic Data).
0 Responses to “Dynamic Data: Putting A New Dress On An Old Model”
Leave a Reply