Meta-Meta-Programming … and I like it

I have a client that needs to rapidly create websites that are similar in functionality but needs to make changes to the data model (sometimes significant changes) and have the UI get updated with it, turning around a change within the day.

For this, I decided to base a solution around ASP.NET Dynamic Data for two main reasons: 1. It’s scaffolding concept and 2. The “generated code” has been tested already, shortening the testing cycle as rapid changes are released.

Of course, the out of the box user experience with Dynamic Data leaves much to be desired and is a little too simple for our needs so it requires some customization.  Once the customizations are done, they can be re-used over and over again but ONLY if they are written against a meta model so that they can apply to any entity on our model, not just coded against known entities, etc.

So what’s “Programming”?

In the normal case, programming is simply putting down the instructions required to make our applications work.  This still holds true in Dynamic Data and other “frameworks” … we are just walled into a set of constraints and conventions.

So what’s “Meta-Programming”?

In Dynamic Data, when creating customizations we have to interrogate the meta-data about the model and code against that instead of directly against the known model. We already have the Type object in .NET to discover much of what we need about the model (data type, field names, etc.) and we can enrich this model with attributes for information like descriptive names, validation rules and so forth.

This makes typical “programming” tasks more challenging starting with simple tasks like presenting the data on the screen to querying the data source without actually knowing the model ahead of time.  LINQ queries change from a simple query syntax to expression trees.  Once you get in the right mindset … it’s kinda of fun.

So what’s “Meta-Meta-Programming”?

This is where the real fun starts.  In Dynamic Data, we are using Model-First Entity Framework to essentially drive the entire application.  This generates the model, which we mark up with the metadata so we can “meta-program” around it.  But what if we can also generate the metadata?

By default, the Entity Object code generator creates decent classes which match the model, play nice in OOP and who’s persistence is managed though the generated ObjectContext. But there are lots of fields on the Entity Model which are largely untouched. What if we could “program” the entire application through the Model and with maybe a little side of metadata on the attributes?

To begin to accomplish this, we ditched the default code generation and downloaded (Nuget rocks) the EF5 Entity Object T4 template.  We then began to generate our metadata through addition fields on the model (DefaultValue, Is Nullable, Documentation).  So the T4 template with these additional fields become our meta-meta-programming tasks, we meta-program the UI to react to the metadata, and we toss in some good old fashioned programming when we get sick of expression trees and reflections.

I may write about the T4 template we created but just contact me if you want a copy in the meantime.

Advertisements

Atlas – AJAX Programming for the .NET 2.0 Framework

I just completed a webinar on using Microsoft’s Atlas framework for creating "AJAX" applications in ASP.NET 2.0.  Despite that one of my demos failed to work (my poor, poor typing skills) the webinar went well.
 
The webinar started with an introduction to AJAX with a little (read: cheesy) demo of AJAX using a text editor and a browser.  The presentation moved into an overview of the Atlas framework and a decription of the client- and server-side architectures and improvements.  Of course, this all included some more cheesy demos (yet representitive) of:
  • Client-Side O-O API
  • Client-Side Declarative XML
  • Server-Side Control Extenders
  • Server-Side Partial Rendering (UpdatePanel)

For anyone that wants them … here are links to my slides and code:

For more information I recommend you check out the Atlas home page at: http://atlas.asp.net .

Events not firing for controls in the HeaderTemplate of a Repeater

Problem
At a client’s site, we were making extensive use of Repeater controls to render data piped to it via a custom entity and collection.  In addition, we wanted to implement sorting in the repeater using LinkButtons which were rendered in the HeaderTemplate of the Repeater.  So for so good … seems like a pretty reasonable request and it works. 
 
In addition to this, we also hosted these Repeaters (amongst other UI elements) in a UserControl so that we could take advantage of the WYSIWYG design features of Visual Studio.Net.  These UserControls, in turn, were to be re-used in several aspects: hosted on ASP.Net web pages, loaded dynamically into server controls, and loaded dynamically into SharePoint WebParts.  The last was the most important as prior to ASP.Net 2.0 there are no easy WYSIWYG methods for creating WebParts so we decided to host UserControls inside WebParts.
 
At this point, the UserControls worked just fine when hosted on an ASP.Net web page leading us believe everything was ok.  We dropped the user controls onto the test web page and used the Page_Load event to pass data into the control to be rendered.  The LinkButtons that were in the header of the Repeaters re-sorted the data and everything looked great.
 
Next came the WebParts
At this point we created WebParts that were designed to host the UserControls and pass along any personalization and configuration properties from SharePoint’s Storage to the UserControl.  Again, everything appeared to be working great with one exception: The LinkButtons were no longer sorting!  I figured it had something to do with the fact that I was lazy and did all of my work in the RenderWebPart method (no need to lecture me; I have learned my lesson).  I moved the call to Page.LoadControl to the CreateChildControls() method where it should have been the entire time.  This would assure that the UserControls were created and added to the Page’s collection in time for the events to fire.  Almost there….
 
Still … the events did not fire but I still had a little bit of laziness left in me.  My thoughts went back to when I gave SharePoint WebPart development training.  In my own words were: "You should create the controls in CreateChildControls, load them in the Load event of that control, and ONLY render them in RenderWebParts."  Of course, there is a reason for this which I now realize. 
 
In a Repeater control, the HeaderTemplate (and FooterTemplate) is not created until the DataBind event is called and, thus, any controls in the template will not exist until that happens.  In my laziness I had not moved the actual loading of the data in the UserControl out of the RenderWebPart method so while the control itself was getting added to the controls collection at the correct time, the LinkButtons did not exist.  Following my own advice I moved the loading code into the UserControl’s Load event (on the web part) and now everything works as advertised.
 
The Moral
Having passed my ASP.Net MCP … I should have known better.  Having uttered the words in training that would have prevented this from being a problem in the first place … I should have known better.  Being lazy at the wrong time … priceless.