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!”
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.
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.
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.
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.
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.
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.