What is SchemaProber?

The main purpose of SchemaProber is to provide a lightweight representation of a database schema. It doesn't do anything except relay information from the database. Here's the class diagram for SchemaProber:

HyperActive uses the SchemaProber simply for enumerating the database objects it needs to model as ActiveRecord classes.

The main pluggable component in the SchemaProber is the IDbProvider interface which looks like this:

The intention being that one could create a provider for any database. Currently, I only have the Sql Server implementation, SqlServerProvider, and I'm in the process of writing a Firebird implementation.

Here is a fairly stupid example of using the SchemaProber. All it does is display some simple info about a database schema. And yes, the functionality can be created a million different ways, the intention of the SchemaProber however was to be lightweight(no external dependencies beyond the .NET framework) and interchangable with many data providers.

Refactoring HyperActive

I've been thinking a lot about HyperActive lately. I hit a wall with the project, it was not as flexible as I wanted. I violated the DRY in a few spots and I think that hurt the project from a usability standpoint. One thing that bugs me is that the options are sprinkled in different flavors and in different spots throughout the code, from the console app to the configs.

I used it for the activerecord classes supporting this site but it didn't generate everything the way I wanted and needed some manual intervention. I need an exception type mechanism, some type of way for the generator to be a little more flexible by parsing a file or something at runtime. So when it hits table whatever, the exception would tell the generated to take an alternate path rather than the default behavior, whatever that means. I'd want that defined within the exception mechanism. It needs to be way simple though...

HyperActive is really three projects, SchemaProber, Dominator, and HyperActive.Core which is built on the first two. SchemaProber and Dominator are useful on their own, and i'm thinking about focusing on making those a little more useful. The Dominator has a pretty good fluent interface but it can be better. The ActiveRecordGenerator implementations do a pretty good job too of using fluent interfaces but I need to make the methods a little more high level, right now in order to extend or create your own ActiveRecordGenerator implementation you need to know some intimate details about what the actual activerecord class needs to look like when it's generated.

Who wants to write yet another grid?

How Not to Sell to Developers

Recently, we've been trying to roll out a Microsoft CRM solution. One of the consultants hired to help us get the project off the ground gave us a little sales-ish demo the other day. One of the highlights of using Microsoft CRM, was that now, we developers don't have to write "yet another grid control".

I'm a developer. I've written tons of code responsible for generating grids. I've written "yet another grid control" many times. Why? Because not all grids are created equal. Needs vary from project to project, site to site. Telling me that I no longer have to develop software is not selling to me, it's selling to the people who hire me for my services; and it's selling them a silver bullet.

No Silver Bullet

How true is that? There is no silver bullet. If you've ever used or played around with Microsoft CRM, one thing you'll notice right away is that it doesn't work in FireFox. I hate IE. It's a pain in the ass to develop against for both css and javascript. So that's a major bummer. All grids look the same in Microsoft CRM. Yay! That really is a good thing. If it's done right. However, the html and css generated for the built in grid is a mess and very difficult to duplicate. Why would you want to duplicate the style? Well, you want to show data in a grid and that data didn't come from the CRM database? Well ya better start rollin "yet another grid control".

One More Time, Who Wants to Write Yet Another Grid? I DO!

I like coming up with unique solutions to problems, including grids. How simple can you make the markup? how easy can you completely re-skin a grid without changing any code except for the stylesheet? Those are areas I like to focus on, and solve in tons of different ways. Sorting. Pagination. In place editing. There are so many situations where you either need or don't need those features. Not using .NET? Start writing your own grid. Not using IE? Start writing your own grid. Telling me that Microsoft CRM contains a grid so that I don't have to write "yet another grid control" is not a selling point(for me).

Microsoft CRM offers a lot, it's just not a silver bullet.

Oops... Let Me Help You

Garrett Dimon has a great 404 page. I was randomly surfing around and clicked a link this link which brought me to this::

That's a great 404. Why? Because it gave me an option that lead me to where I needed to go.

MonoRail + Prototype = Ajaxy Goodness

I'm trying out some ajax stuff in MonoRail tonight. As a fan of keeping it simple, I usually use Prototype for all things javascript. I like AjaxPro because it does a lot of stuff behind the scenes that makes the developer experience very pleasant. All you have to do is mark any method that should be called from client side javascript with the AjaxMethod attribute and when the page is loaded the appropriate javascript is autogenerated. That's awesome.

In MonoRail things are a little different. Since we have fine grained control down to the method level essentially, there's no need for a framework to do any runtime code generation. So you can have your client side javascript look like this:

$('btngo').observe('click', function(){
    this.disabled = true;
    $('indicator').show();
    new Ajax.Request('/home/sayhello.ashx', {
        method: 'get',
        onSuccess: function(response){
        	$('btngo').disabled = false;
        	$('results').innerHTML = response.responseText;
        	$('results').show();
        	$('indicator').hide();
        }
    });
});

1
2
3
4
5
6
7
8
9
10
11
12
13

Notice the url being called? /home/sayhello.ashx. This resolves to a method on the home controller that looks like this:

public void SayHello(){
  this.RenderText("Hello World");
}

1
2
3

And that's pretty much it, wicked simple.

Severing SubText

Whew...OK. My full MonoRail solution is up, and I've removed all things SubText. In it's current state it pretty much sucks, I have no bells and whistles and there many annoyances but the goal was to remove the SubText ties so I can fully move ahead with all things MonoRail. Anyway, more in a bit.

Nice Surprises - Fluent Interfaces

As I was going through my code, making changes to the test framework for testing generated code, I was thinking it would be nice to have some fluent interfaces on some of the methods.  How I usually start, is by writing how I'd want to use the code.  So assuming this code:

using (DomTester dom = new DomTester(myNamespaceDeclaration)){
}

I started typing what I wanted.  First things first, I needed an easy reference to the compiled type instance, so I typed dom.Type( and the intellisense showed the member was already there!  What happened? Apparently, I already had this thought of fluent interfaces before and added the code for it then swiftly forgot about it completely.  Anywho, so the framework is wired up to do this now:

Assert.IsTrue(dom.Type("HyperBlog.Data.Post").InheritsFrom("ActiveRecordBase`1", "Post"));

And that verifies that the code I generated and compiled, was a type of HyperBlog.Data.Post and it inherits from ActiveRecordBase with a type parameter of Post. It's genius!

How to Test Code Generated Compiled Code

HyperActive is not as flexible as I need it to be. I'm using it in a production environment, it's active code generation and comes in handy for regenerating the database schema anytime I feel like it.

I do lot's of code generation in HyperActive, hell generating code is the entire point of HyperActive. But testing the framework behavior is difficult. I haven't found much online about how to test code that was auto generated and compiled by a framework.

In my quest to improve the usability of HyperActive, I need to test various database conditions, but without actually creating a database with test table schemas, and then running tests. My goal is to be able to mock a TableSchema instance, run it through an ActiveRecordGenerator, and verify that the code that was generated is what I expect it to be.

So basically, if I have a table named order, with identity primary key named order_id, and I run it through an ActiveRecordGenerator, I would expect a class was generated named Order, and for my naming scheme, it would have a primary key property named ID. I need to ensure that not only did I create the write text slash source code, but that what was generated could actually be compiled.

All of those steps need to be behind the scenes however, cuz I ain't typin all that code in for every test. So here is what I came up, this is an example of the syntax I use:

using (DomTester dom = new DomTester(nsdecl)){
  Assert.IsTrue(dom.ContainsType("MyApp.Data.Order"));
  Assert.IsTrue(dom.ContainsProperty("MyApp.Data.Order", "ID"));
}

In the above code, it's assumed that nsdecl, just a local variable,  is the result of an ActiveCodeGenerator generating a NamespaceDeclaration that's ready to compile.  In the DomTester constructor the code is compiled in memory, and loaded into it's own AppDomain.  Since it implements IDisposable, when the block finishes it will unload the AppDomain.  I'm not totally in love with this, BUT, it does ensure that I'm generating code that looks the way I want it to look and can actually compile.  More on this later.

Monorail - AutoMagically DataBound Parameters

Form Parameters

Another cool thing about MonoRail is how it can wire up parameters for you. This is similar to how AjaxPro and I'm sure tons of othe frameworks do it. AjaxPro let's you do something like this:

[AjaxPro.AjaxMethod]
public string SayHello(string name, int age){
  return "Hello " + name;
}

On the client side you might call this method like this:

//here's some javascript to call the method:
function sayHello(){
  YourNamespace.SomeClassname.SayHello('chris', 37, function(response){
    alert(response.Value);
  });
}

What's interesting with this code is that there's no casting and grabbing of values from Request.Form or Request.QueryString, AjaxPro does that for you behind the scenes. This is similar to what MonoRail does for you in the controller. Using the SmartDispatcherController, you declare some form fields. Click on the following image to see the html form code:

Then in the controller you create method that handles the form like this:

public void SaveComment(int postid, string title, string name, string email, string yoururl, string commenttext){ 
  //all of the parameters are mapped up to appropriate field and there's no mapping needed.
}

Monorail View Components

Don't Repeat Yourself

I have a lot of code duplication I need to get rid of in my views, so I decided to check out View Components. I ran through the intro page, downloaded and took a look at the samples and in no time had my first view component ready to go.

The Archive List to the Right ->

The archive list to the right of this is a view component, and there is VERY little code. I added some caching for the archive data, then created a view component that generates the simple list.

Here is the C# code needed for the view component:

namespace HyperBlog.Web.Components {
  using System;
  using Castle.MonoRail.Framework;
  using HyperBlog.Data;

  public class ArchiveComponent : ViewComponent {
    public override void Render(){
      PropertyBag.Add("archives", 
        DataCache.GetArchiveList());
      base.Render();
    }
  }
}

The view for the archive looks like this:

And then using the component takes this: