Welcome to Metadata Island. It’s a beautiful place. Rich in resources that represent the hard work of application designers, business analysts and their customers. Those very long specification meetings. Countless missed meals typing up specifications. Yes we have all contributed to the paradise repository called, Metadata Island. Not to mention this vast metadata resource that sits dormant which companies paid tens of thousands of dollars to create. If you were to get in your boat, the lone guy managing the metadata can be heard on the beaches waving his arms and crying out, “Hey!! I’m over here!”
The Problem
Bottom line; the once thought out and complete metadata never gets off the island after it arrives. Current development tools are not set up to take advantage of developer metadata during the form or code generation processes. Anyone ever used Microsoft Access? Since Access 1.0, the program utilizes the developers metadata stored in the table object. The form and report designers expose this metadata in a ComboBox allow the developer to drag a field to the design surface and Access will create the control and corresponding label. It also has Mr. Wizard that creates forms and reports for you.
Why should our developers have to retype ToolTip text into form property grids? Why should developers spend time entering data into property grids at all, especially the same data that is sitting on Metadata Island? Beside being error prone, software companies are having to pay another person to enter this same data into yet another interface.
Why Did I Write This?
Before I get much further I must explain the context of this blog post. First and foremost, I’m not a Microsoft finger pointer, not by a long shot. We have fantastic tools and outstanding developers that I have deep respect for standing behind them.
I have been to two recent Microsoft events, MIX08 and the 2008 Microsoft MVP Summit. I didn’t hear anything in any keynote, presentation or off-line conversation about any plans for Visual Studio or Visual Studio related tools to consume developer metadata. I feel so strongly about this, so I wrote this blog post to raise the awareness of this need and to demonstrate how simple this is to accomplish.
I like Visual Studio 2008 and Expression Blend 2 and 2.5. I like that I can open a designer and the tool creates classes for me. Someone worked real hard to deliver that tool. Where I get disappointed is when I have a great tool that I can’t use because it can’t consume my metadata.
For example the LINQ to SQL and SQLMetal tools don’t currently add XML comments to my classes or add my attributes to my properties. But this would be easy to accomplish.
Currently there is no way to use the tools and have them populate a control’s properties based on my metadata as the control is being dragged to the design surface. But this would be easy to accomplish.
Video Demonstrations
Please watch the two below videos. The first one demonstrates a program I wrote that uses metadata to generate WPF forms in milliseconds. It can also generate individual controls The second is a short video on the program and how simple it was to write.
When I made the videos, this was using the Alpha One version. Since then I have updated it after getting suggestions. The version in the video works great but has been updated and now looks like the version at the bottom of this post.

The video links require Microsoft Silverlight 1.0. If you do not have it, you will be prompted to install it when you click one of the links. After the short installation is completed, close the browser window that you did the install in and re-click the video you want to watch. You can also download it here. Windows XP or Vista required.
Metadata Form Generation Video
Metadata Form Generation How I Did It Video
The Solution
We need bridges from our tools to Metadata Island. Bridges is such a friendly and happy word. The phrase, “bridge building or building bridges” is normally used in the context of good, of creating relationships or joining separate objects.
After watching the first video, no one can now say, WPF is not RAD capable. In fact this simple tool is way faster than the great Winforms designer. I spent a days time thinking the tool out, writing and testing it.
I have been thinking about metadata and code generation since I wrote the Visual Studio 2008 Designers and Code Generators; You Have Overlooked (…) blog entry.
I have come up with two bridge building methods I think would work. Of course there are much smarter architects and developers working on tools than me, so maybe they would have a better solution that what I’m proposing here. I’m just praying the ball gets rolling in time for the next release of Visual Studio or possibly a service pack to Visual Studio 2008.
Solution A: Bridge Provider Model
This would be the simplest solution to implement and one that completely decouples the tools from the developers.
In each Visual Studio Solution the developer would place a .dll in the MetadataProvider directory of the solution that was decorated with the required attributes.
When Visual Studio opens the solution, it looks for it, similar to the way it currently does for Visualizer .dlls.
Here is the workflow. When LINQ to SQL or SQLMetal needs to write a class or property object they pass the class name and property name and the MetadataProvider either returns a string or nothing. If nothing, then the tool simply uses its default implementation like it does today. If a string is returned, then that string is used for that object. This would allow developers to create the property with XML comments, attributes and property getter and setter code that they want to use. This way the code the the LINQ to SQL designer generates now looks exactly like code I would have hand coded. Now everyone is happy, very happy. How easy would this be to code into the current tools?
If the developer wanted to generate a form, they would select a business object class that would be used to populate a Data Grid like my program and then generate the code. So in this case, Visual Studio would be interacting with the .dll in the MetadataProvider directory twice. Once to fill up the grid and once when each object is created. Again, very simple workflow and almost zero impact on the current tools.
Advantages
The major advantage to this solution is that it completely decouples the tools from the solution. The tools do not have to be concerned about metadata management. Just call the provider and use what it returns.
Solution B: Metadata Model
This solution would require that a metadata model be established and then developers could populate. This model would be consumed by the tools during object construction.
This model would require that the solution expose templates that could be modified so that the constructed classes, properties and controls be generated exactly if a developer had hand coded them.
Program
I have receieved a few emails about the program so I’ll give the overview.
I used the Infragistics xamDataGrid in the above application for very easy editing of the individual metadata objects.
Most of the columns are editable. The control type column is a ComboBox and the two button columns allow the creation of the control by clicking the button to copy the control to the clipboard as in the demo video or allow the control to be created by dragging the button to a Visual Studio or Blend XAML editor and the control is created there.
You can see I’ve also have put my Code Generator here also. I’ll post some more videos soon on this entire application and demonstrate how RAD WPF development can be.
Close
My program is not a templated solution. It’s coded to generate code they way I would write it. This makes my program very useful to me and anyone that subscribes to my methods and Core library that I have written. We also have a super clean metadata store for our applicaiton generation.
Until the tools catch up, I hope this encourages you to start mining your own rich metadata stores and bringing that well thought out data into your development cycles.
Have a great day and thank you!
Just a grain of sand on the worlds beaches.




May 9, 2008 at 2:11 am |
Cool demo Karl. It’s kinda like we’re back at the .Net 1.1 days with a new, fledgling technology. I remember writing code-generators for my forms, code-behind and stored procs back in the day… and it only took the Visual Studio team 3 years to catch up
May 9, 2008 at 2:35 am |
Great post as usual. You might be interested at ASP.NET Dynamic Data which is Data Driven RAD asp.net development. Its architecture is Page/Field Templates + MetaDataModel + LINQ2SQL(Entity Framework, LLGenPro). it generates pages on the fly. But one can override/extend pages through convention.
Since WPF/SilveLight (XAML) is similar to ASP.NET templates, one could build XAML template based + MetaData + LINQ2SQL for RAD WPF/SilverLight application.
ASP.NET Dynamic Data also share Routing with ASP.NET MVC, the same concept “Routing” can be useful for SilverLight/WPF page/form navigation.
All in all, good reference for your path.
Kevin
May 9, 2008 at 2:47 am |
Great article dude…
May 9, 2008 at 2:50 am |
Let me clarify the above post, RAD WPF/SilverLight application should be small to medium LOB Data Entry application, same as ASP.NET Dynamic Data targeting.
Kevin
May 9, 2008 at 5:46 am |
Kevin,
Thank you for you comments. Currently this is what I’m doing with my metadata.
When cross a bridge to Metadata Island, get my information, this is what I’m currently doing with it:
1. Design Time Form Generation
2. Run Time Dynamic Form Generation
3. Design Time Control Generation
4. Run Time Dynamic Control Generation
5. Stored Procedure Generation
6. DAL Class Generation
7. BLL Class Generation
8. Business Object Generation (including all that declarative validation, character case correction, logging, etc)
To the above, add business logic and it looks like you have a VERY RAD WPF development system in place.
I use the dynamic forms and dynamic controls to replace the simple forms like the pull down table maintenance.
The rest of the forms we actually have a UserControl form that gets loaded into the MDI system.
But COULD this system be used to create an end to end completely dynamic application, yes.
Cheers,
Karl
May 9, 2008 at 5:48 am |
Kevin,
Thank you for you comments. Currently this is what I’m doing with my metadata.
When cross a bridge to Metadata Island, get my information, this is what I’m currently doing with it:
1. Design Time Form Generation
2. Run Time Dynamic Form Generation
3. Design Time Control Generation
4. Run Time Dynamic Control Generation
5. Stored Procedure Generation
6. DAL Class Generation
7. BLL Class Generation
8. Business Object Generation (including all that declarative validation, character case correction, logging, etc)
To the above, add business logic and it looks like you have a VERY RAD WPF development system in place.
I use the dynamic forms and dynamic controls to replace the simple forms like the pull down table maintenance.
The rest of the forms we actually have a UserControl form that gets loaded into the MDI system.
But COULD this system be used to create an end to end completely dynamic application, yes.
Cheers,
Karl
May 9, 2008 at 5:49 am |
Andrew & Marlon,
Thank you for your comments.
Chers,
Karl
May 9, 2008 at 6:23 am |
Karl,
Another great post – couldn’t agree with you more on the amount of time developers can waste “plumbing” a form with endless property settings. What’s worse is that this also leads to many inconsistencies throughout large applications as the properties are replicated across hundreds of forms/pages.
I notice that you mention in the comments that you use the meta-data to produce forms/controls both at design time and run time which is nice. My preference is actually to have the developer layout the forms using the designer but have the meta-data automatically derived via the Binding at run-time. The benefit I see to this approach is that the XAML stays very clean. A control has only its bound property attribute specified, plus any other properties that are form specific overrides to the meta-data defaults (which must appear after the binding). This means there is no need to regenerate the forms when/if the meta-data changes, and the XAML deals purely with layout.
For example a TextBox is bound to a “Name” field using: <TextBox Text=”{Binding Name}”/> . At run-time the control width, security, tooltip, help ID, validation etc. are applied when the binding is resolved.
Now – as yet I haven’t managed to get this working in WPF – but I think I’m close. But I have taken this approach to dynamically create WinForms forms/controls using a custom built XAML engine. Applying labels to control is also possible taking this approach – even to the extent of aligning the labels automatically based on the maximum label in a given column.
Anyhow – just my 2 cents – enjoy reading your posts – thanks for taking the effort in putting them together!
Cheers,
Nigel
May 9, 2008 at 6:31 am |
Nigel,
Thank you for your kind comments and for sharing your ideas for cool solution.
I had done the SAME exact thing when I attended my .NET school in 2003. Dynamically loading metadata at runtime. I was showing them you could load differents sets of metadata for each different customer that application is deployed to. Customized tooltips and captions showed well in the class I gave at school. I used XML files for the metadata, but this could also come from resource files, the database, etc.
This would be easy to do in WPF, as you can use the same code you did in Winforms.
I was just concerned about performance and really didn’t need the flexability.
But this is what I love about the computer field and developers. We can disign and deliver software that meets out needs!
Best to you and thanks again for sharing!
Karl
May 9, 2008 at 6:31 am |
Hmm… looks like WordPress didn’t like me using XML in the comments. The TextBox example should have been:
<TextBox Text=”{Binding Name}”/>
May 9, 2008 at 6:35 am |
Nigel,
I edited your comment and placed the code in for you. Your first comment now has the above text.
Cheers,
Karl
May 10, 2008 at 9:20 am |
[...] Metadata – A Voice Crying in the Wilderness, Hey! I’m Over Here (Karl Shifflett) [...]
May 16, 2008 at 4:45 pm |
[...] reappearing in the cloud? Phil Haack on DotNetRocks Steve Main points to Brian’s blog on F# Metadata – a Voice Crying in the Wilderness, Hey! I’m Over Here Jon Skeet on The Beauty of Closures Mike Taulty links to a way of Mocking LINQ to [...]
July 16, 2008 at 10:51 pm |
Nice Article, am waiting on the LOB articles to continue.
Is the code for this going to be available?
July 17, 2008 at 8:20 pm |
Andrew,
I’m working on a full blown product that I will give away. It is template based and working REALLY GOOD now. I’ll be writing a cool UI and Metadata management for it. I’ll include all the templates necessary to generate all the code you’ll need. You can VERY easily modify and add new templates.
I’m going on a cruise to Alaska the first week of August and hope to finish or get very close to finishing during the cruise. The name of the product is Ocean. Figured what better place to write a product called Ocean, but on the water.
Cheers,
Karl
October 15, 2008 at 3:58 am |
[...] in May of 2008 I wrote this blog post: Metadata – a Voice Crying in the Wilderness, Hey! I’m Over Here. This was a call to architects to consume the warehouses of metadata that most projects have [...]
December 11, 2008 at 5:15 pm |
[...] – bookmarked by 4 members originally found by princhoz on 2008-11-05 Metadata – a Voice Crying in the Wilderness, Hey! I’m Over Here [...]