Most people believe dogfooding is the perfect way of ensuring the quality of the software you're creating. I couldn't agree more.

The only problem is that when you use your own software, you always have the feeling that it's not quite "done". There's always something that you can do better, always something that can be improved, always some features that you feel would be nice.

Especially when building a framework this can become a real problem because you never feel done. Another problem is making sure your framework maintains backwards compatibility with previous releases.

Well, I just mentioned this because I finally decided to freeze version 2.0 of ProMesh.NET and get it ready for release. Release candidate 3 has just been published on CodePlex

A few weeks ago, a fellow developer asked me why I chose to make my projects open-source. That was a pretty good question because when you look at it: compared to just building a framework for your own use, it makes life more complicated: you have to write documentation, support users, and more headaches.

I didn't have to think long before I could answer that question: releasing a custom framework as open source forces you to be disciplined about your code and documentation. After all, you can't afford to write code you are ashamed of, can you? If you write software for your own use, you tend to write code that... well... sucks.

And of course, let's not forget the whole point of open source software: letting other developers contribute. It creates a dynamic that you would never get when you're just building and using your own little framework

If all of the above sounds like a bunch of crap, it's probably because I'm not a native English speaker, or ... it is just crap

•

ProMesh.NET, the .NET MVC Web Framework I released in the "open" last month is still waiting for it's first real released version. It's actually ready to go, but something is holding me back: documentation. Sadly, writing documentation is a tedious process, which always takes longer than you'd like...

In the world of intellisense-assisted code editors, documentation has become less important than in the past, but I personally think it is absolutely necessary to have proper documentation for a library/framework, be it commercial or open-source.

On the other hand, after looking at some other open-source .NET libraries out there, I start to wonder if it would be better to just "officially" release it and worry about documentation in the weeks after. An awful lot of (more or less) successful open-source frameworks seem to have little or no useful documentation. In many cases, documentation is updated after a release has been published (sometimes weeks or months later).

So I'd like to hear your opinion on this one. What's the best strategy?

1. Release now and publish the full documentation later when it's done
2. Release now and publish the current state of the documentation (while continuing adding documentation)
3. Wait until the full documentation is done.

•

Let me just say that I am pretty impressed by what Miguel De Icaza and the other Mono guys have accomplished by creating Mono.

I have never been impressed by Linux and I am not surprised by the slower than expected adoption of the operating system, despite huge efforts by Novell and Red Hat. To me, the main reason is the lack of standardization in the different distributions. Setting up and configuring a Linux system is never the same. Different vendors use different front-ends (Gnome vs KDE), the file systems are organized differently, boot procedures are totally different, ...

But, I have always been intrigued by Mono, the .NET platform for Linux which is "sponsored" by Novell. Mono has always been pretty up-to-date by implementing new .NET stuff and compiler features as soon as (or sometimes even sooner than) Microsoft made them publicly available

I was a little curious to see how ProMesh.NET (MVC Web Framework for .NET 2.0) would run on Mono (if at all), so I did the following:

• Download the VMWare image with a pre-installed Mono installation on SUSE Linux 10.2
• Download VMPlayer (free)
• Copied the latest ProMesh.NET source tree to the virtual machine
• Fired up MonoDevelop
• Compiled the framework... Works (well, it compiled)
• Copied the ProMesh.NET demo application to the virtual machine
• Compiled the demo app... Works!
• Started xsp2.exe (the lightweight .NET web server for Mono)
• Opened the index.ashx page using FireFox: WORKS
• Went through the complete demo site. Everything worked!

I was utterly amazed by the painless process of compiling and running a ProMesh.NET application on Mono, something I've never tried before (I did have some previous experience with MonoDevelop, but not a lot).

This is pretty exciting stuff, knowing you can just grab your ProMesh.NET web application, dump it on a Linux box and run it from a Linux web server.

Mono team: good job!!

•

I’ve been using AjaxPro for a few years now, and I must say that I have been very happy with it. It was even integrated with ProMesh.NET, meaning you just had to call RegisterTypeForAjaxPro() and the method stubs were being generated in the HTML output.

I was in the process of checking out some JavaScript frameworks, when I came across jQuery. Pretty cool stuff, although not that much different from Mootools, which I have been using for a few months. The Ajax stuff in jQuery is pretty easy to use and started playing around with it until… Hmm, I am moving away from the point of this article.

Anyway, not that all of this matters, but I started thinking about how hard it would be to offer the same functionality that AjaxPro offered, all integrated in the ProMesh.NET framework.
Calling the server methods was a no-brainer, because the framework already supports calling specific methods on Controller objects. The “hard” part was returning objects to the client as  JSON strings. I didn’t feel like writing my own JSON generator, so I started checking out some open-source stuff.

I found the following products:

• AjaxPro JSON Parser (custom license)
• Jayrock (LGPL License)
• Newtonsoft JSON.NET (Creative Commons Attribution License)
• LitJSON (Public Domain)
• JSONSharp (GPL License)

All of these did exactly what I needed, so it was hard to choose. What was very unusual, is that one of these products, LitJSON, had a public domain license (i.e. no license at all). Not that the licensing for the other offerings was too restrictive to be included in ProMesh.NET, the thought of not having to worry at all about licensing made me decide to take a better look at LitJSON. The product seems to be very solid and well written, so I added it to the source tree of ProMesh.NET. I will include it with the 1.1.0 release of ProMesh.NET, but with a notice in the release notes that the JSON stuff hasn’t been tested as thoroughly as it should have been.

So, to make a long story short: ProMesh.NET now supports native Ajax method calls using jQuery or another JavaScript framework. Currently, only the jQuery JavaScript provider has been included in the latest build, but you can plug in any provider you like (using the IAjaxProvider interface).

•

Scott Bellware wrote an interesting article “Monorail vs. Rails Isn't a Meaningful Question” which touches the subject of choosing a technology for building web applications.

The question “if you're building web apps on .NET, what leads you to assume that you should be building on .NET?” came up twice in his post. While this is a question a technologist might ask, it is a no-brainer for the stake-holders.

Think about this: As a stake-holder, why would you use Ruby (on Rails) when it is at least 100 times harder to find Ruby developers than it is to find good .NET developers? You wouldn’t. Even if I was a die-hard Ruby enthusiast, and I needed to build a “real” web application my company depended on, I would never pick Ruby on Rails.

So obviously .NET is a safe choice, but that doesn’t necessarily mean you should use the ASP.NET framework. There are other (better?) frameworks available for building web applications in .NET (I even doubt that the Microsoft website is using ASP.NET Web Forms for all its content). It’s not that hard to teach a .NET developer how to use MonoRail or ProMesh.NET or (…), but it is a lot harder to make a C# developer use Ruby (on Rails).

Ruby may be the better technology for web apps, .NET seems (for now) to be a better (business) choice for real web applications.

•

One of the most powerful features in .NET is the ability to use reflection to do all kinds of neat stuff at runtime, like

• Find out what properties, fields, methods, etc. are in a class
• Create objects without knowing their type at compile time
• Call methods by name (even private ones)
• Check attributes on classes, methods, fields, …
• …

The web framework I built over the last few years, ProMesh.NET, relies on reflection for a lot of the features it offers. Often though, I am asked if the heave use of reflection doesn’t have a significant impact on performance.

My answer usually is: YES, but it doesn’t matter. Now you probably think that I don’t care about performance or that I’ve had too much too drink. None of the above. I’ll explain:

In ProMesh.NET, there’s a feature that allows you to just declare session properties in your class that will be constructed at runtime, like this:

   private SessionProperty<string> _mySessionVar1;
or
   private SessionProperty<string> _mySessionVar2 = new SessionProperty<string>();

You don’t have to initialize _mySessionVar1. The framework uses reflection to construct the object.

Creating _mySessionVar1 is about 20 times slower than creating _mySessionVar2. Shocking? Yes. Unacceptable? No!

The reason why it is not unacceptable is that it takes 2.2 µs (microseconds) to create _mySessionVar1, and 0.12 µs (microseconds) to create _mySessionVar2. These figures include dynamically iterating the over the class members, determining their type and looking up the appropriate constructor. This is the simplified code which creates the fields at runtime:

foreach (MemberInfo member in GetType().GetMembers())
{
  if (member is FieldInfo)
  {
    FieldInfo field = (FieldInfo) member;

    ConstructorInfo constructor = 
          field.FieldType.GetConstructor(Type.EmptyTypes);

    field.SetValue(this, constructor.Invoke(new object[0]));
  }
}

Considering this happens when a web page is requested, which usually involves some database access, a little disk access and some other time-consuming stuff, a complete web page request takes between 50ms and 2000ms. Assuming we have 20 session variables to construct at runtime, the overhead is … between 0.08% (worst case) and 0.002%.

So, yes it is MUCH slower, but it doesn’t matter. (not for applications of this kind)

•

There seems to be quite a bit of demand for a preview of ProMesh.NET, my MVC-type Web Application Framework for .NET 2.0. To satisfy this demand I decided to publish a small demo application (with source code) on CodePlex, which includes the current compiled ProMesh.NET assemblies

The demo application contains a web project and a unit testing project. The web application shows the following features:

• Mapping of client variables to method parameters (even url parameters mapped to objects)
• The template rendering engine
• Form handling and validation (very basic in this application)
• Typed session properties
• Application configuration

The unit tests included in the example contain 2 tests:

• Checking if access to unauthorized pages is properly blocked
• Login procedure of a registered user

I expect the first public release (including source code) to be released sometime on wednesday or thursday.

Direct link to the download page on CodePlex: Click here

Update: In the meantime, the first beta has been published.

•

In one of my previous posts, I talked about the separation between code and markup, which caused quite a bit of turmoil, especially from the PHP and MonoRail enthusiasts.

Maybe I didn’t make myself perfectly clear. I don’t have a problem with embedding view logic inside HTML markup, as long as it stays within reason. On the other hand, application logic should be kept on the server (in the controller or deeper layers).

I mentioned MonoRail (combined with the NVelocity engine) because I saw two things I didn’t like:

1. The scripting language goes too far
2. The templates are not designer friendly

1. The scripting language

In my (humble) opinion, a template rendering engine should be limited to the following constructs:

• Looping over a collection
• If…else… constructs for showing conditional blocks
• Embedded variables fed from the server

NVelocity adds macros and variable assignment. These features allow complete programs to be written inside the template, and this is not what we want (again, IMHO)

2. Designer friendly

An HTML template file that can’t be opened by an HTML editing application is worthless. The HTML in the template should also be valid.

The NVelocity templates used by MonoRail don’t satisfy these criteria.

The first problem is that the *.vm files are actually pieces of HTML, but they are not HTML documents because there’s no <html> and/or <body> tag. HTML designer application don’t like this.

The other problem is that the NVelocity templates are not valid HTML. For example, the following fragment is not valid HTML:

<table>
  <tr><th>Header</th></tr>
  <tr><td>Row1</td></tr>
#if (showThisBlock)
  <tr><td>ConditionalRow2</td></tr>
#end
</table>
 

The only markup allowed between </tr> and <tr> is comments. The solution is easy: embed control script inside HTML comments. That’s how I did it, so this is how the template looks using ProMesh.NET:

<table>
  <tr><th>Header</th></tr>
  <tr><td>Row1</td></tr>
<!--$(if showThisBlock)-->
  <tr><td>ConditionalRow2</td></tr>
<!--$(endif)-->
</table>

I hope this post clarifies my earlier post. Don’t get me wrong: I really like MonoRail. In fact when I first read about it, I was surprised by the similarity to what I had written for my own use. I suppose this means I agree on a lot of things with the MonoRail developers

•

In the early days of web development, it was common procedure to write application logic inside your HTML pages using ASP, JSP, PHP, Perl or another early web application development framework.

Of course, back then we didn’t know any better, but don’t you just cringe when you see something like this:

<table border="1">
<%
For I = iRecFirst To iRecLast
	Response.Write "<tr>" & vbCrLf
	
	For J = iFieldFirst To iFieldLast
		Response.Write vbTab & "<td>" & arrDBData(J, I) & "</td>" & vbCrLf
	Next	
	Response.Write "</tr>" & vbCrLf
Next ' I
%>
</table>

I know, this looks pretty simple, and the learning curve to write applications in this way is not that steep, but maintaining something like this is a nightmare.

Microsoft saw the need for something better and came up with ASP.NET. Indeed, at first glance it was a big improvement, urging developers to cleanly separate code from markup by providing the "code behind" way of programming. But if you look closer it was still a mess. Let me tell you why:

• There’s a (very limiting) 1–1 relationship between the view and the code. Every .ASPX has one code behind file, and one code behind file has one .ASPX file. Implementing the MVC pattern is impossible without resorting to a bag full of tricks.
• Events are wired in the markup, so the markup is controlling the application, not the other way around
• The .aspx files are "kind-of" HTML files, but when you try to edit them in a standard HTML editor (Dreamweaver for example), you're in for a (nasty) surprise. ASP.NET tags are not recognized correctly, let alone rendered. So you are pushed into using the Microsoft ASP.NET markup editor, which is the crappiest piece of junk ever built.
• Properties influencing the behavior of user interface elements are defined in the markup. And the other way around: properties defining the look of your application sometimes have to be defined in code
• Standards based HTML/CSS? What standards based HTML/CSS?

To this day, Microsoft is still holding on to this broken development model for web applications. The Java guys had more inspiration in that area: Struts, Tapestry, Wicket, SiteMesh, Spring, ... Good ideas that quickly turned into Enterprise Frameworks that were too intimidating for the average developer (isn't this a pattern for all Java-based technologies?)

Light at the end of the tunnel?

Maybe... Ruby On Rails, MonoRail, DotNetNuke, Spring.NET,... Cool stuff, VERY cool stuff.

Which brings me to the point of this article. While I didn't have time to look at all these frameworks, I am still a little annoyed by the lack of separation between the actual presentation (markup) and the code controlling the presentation. The other day I was checking out MonoRail and was browsing through the samples, and I saw a lot of ASP-like stuff in the HTML markup. Loops, method calls, the whole shebang. I felt thrown back to the nineties.

Maybe I am too religious about this, but I like to see a 100% separation between code and markup (presentation). My requirements for a web application framework are pretty clear:

• Pure HTML files should be used. By pure HTML, I mean that you should be able to give the HTML files to a web designer and let him/her make changes without having to worry too much about these funky codes that these weird developers have put in.
• No hints of any application logic or code in the presentation markup
• The learning curve should be gentle, without losing flexibility and performance
• MVC has to be easy to implement (or included in the framework), without forcing developers to use it. 90% of web developers don’t use MVC, so don’t force them to use it if they feel more comfortable developing in other ways
• Easy Ajax integration (I am not talking about black box toys like Microsoft Ajax)
• Performance! Performance! Performance!

In a few days, ProMesh.NET, the web application framework I have been building, using and improving for the last 4 years will be published as Open Source on CodePlex. It’s a lightweight , fast web application framework that satisfies the requirements listed above and I look forward to sharing it with the .NET community.

•