FlexWiki doesn't get ASP.Net
Note: this entry has moved.
A few weeks ago I had the chance to peek at the FlexWiki source code while helping a team that was trying to integrate a Wiki into an existent website. All my suggestions to them, like “write a custom control to do this or the other” had the effect of only confuse them even more. They were worried about “how to do that in FlexWiki”. Well… it’s an ASP.Net application so you should not have much trouble adding an extra control for instance, that was my simple reasoning, until I saw FlexWiki soure code, of course.
What I saw was really some of the worst coding practices you could use for an ASP.Net application. But the real surprise came after I read the 2nd line that is in every source file:
// Copyright (c) Microsoft Corporation. All rights reserved.
This worried me a bit… -- Why is a Microsoft copyrighted ASP.Net application using some of the worst coding practices for a web application?
Inside the ugly
You probably remember ASP 3.0 common code like the following:
Response.Write (“MyMessyAndImpossibleToMantainMarkupGoesHere”)
Well… FlexWiki contains more than 400 (that is, four hundred) calls to Response.Write and some of them like the one found at WikiEdit.aspx.cs:432 output ~3Kb of html in a single call, that’s as ugly as it can get regarding usage of Response.Write. This includes hard coded CSS class selectors, hard coded markup, etc, thus making customization of “the thing” really a hard task.
But besides the common “bad-usage-of-Response.Write” syndrome that you will find in FlexWiki and some other web apps out there what is really incredible is that FlexWiki doesn’t use any of the major ASP.Net features!! No controls, no state management, etc. I guess if you rename FlexWiki pages from “.aspx” to “.asp” they may even work in ASP 3.0!! J
Getting uglier
By looking at Default.aspx you can easily tell that all its doing is spitting out chunks of hard coded markup and javascript code in a never ending method of ~200 lines in length named DoPage. This is very similar to the rest of the pages they use.
So their approach basically seems to consist in having an .aspx page with the following:
<%@ Page language="c#" Codebehind="ShowNewsletter.aspx.cs" AutoEventWireup="false" Inherits="FlexWiki.Web.ShowNewsletter" %>
<% DoPage(); %>
And a huge DoPage method with all the hard coded markup and script into a corresponding aspx.cs file.
Where are the controls taking to each other, firing events, maintaining state, etc. You won’t find that in FlexWiki, I’m afraid.
So if you ever try to extend it, for instance, adding a CAPTCHA control for validating edits, you are on your own, spending lot of time because of FlexWiki “architecture”.
It’s also hard to understand the reason why if they really wanted to use the DoPage approach (which just in case you haven’t noticed already I think it’s nasty) they did not go for a custom IHttpHandler implementation… (why having a full featured Page when all you’re doing is calling Response.Write?).