I was going to put a rant in here about PHP sucking, but instead I'm going to do something useful and informative. Describe how this blog works.

When I started this blog, I had only used ASP.Net with WebForms. Even though I didn't know anyway to do it better, I could see the shortcomings of pretending HTTP is a stateful protocol. This is because before ASP.Net, I used PHP, which actually taught me quite a bit about the HTTP protocol. I've since abandoned the PHP ship due to stuff like this, but that's another story.

I believe at the time ASP.Net MVC was still pre-release or still filled with bugs, especially for Mono. I was set on using Linode for my hosting because I've never had any problems with them, and I prefer managing Linux servers to Windows... So I had a choice, Use WebForms, or use a different framework. I really like C# though, so I instead created a very minimalistic framework.

This framework eventually got broken up into 3 different pieces of software.

At first, these were all one framework named EFramework, but I since broke them up since they are all useful by themselves as well.

So first up, I'll explain how EView generates everything you see here.

EView is just a single T4 file. I would've broken it up into separate files but at the time Mono had a bug that prevented me from doing it easily. How it works basically is you place EView into a directory, and when you run the T4 file template, it'll read all the files from the current directory and generate a C# file.

So, let's do a simple example. You have a folder named Templates and 3 files, EView.tt (the T4 file), IndexView.html, EntryView.html

So, you run EView.tt. Visual Studio (or MonoDevelop or whatever) runs the T4 template during design time. EView will scan the folder it's placed in. It finds IndexView.html and EntryView.html

Now let's explain. What's that weird {@ thing at line 2? This is an EView directive. EView has blocks like { } The symbol after the { and before the } indicates what the directive is. The @ directive is for variable declarations. So basically, in the view class it generates, it'll add the public variable Entry of type IEView to it. IEView is the interface that all EView views implement. After that it looks like plain HTML until {=Entry=}. The {= directive tells EView "put this variable's value here. So it wants to put theEntryvariable there. EView is smart enough and knows that Entry is a View, so it callsEViewRender at that point.

So basically, this all generates a view class like this: (more complicated than this, but to be easy to understand, this example is simpler)

So as you can see, it's very powerful really, while views are really simple to create. No weird XML tags to use, or other crao. You just write your HTML and use a { } blocks to describe how the view should be dynamic. It supports many more operations than shown here such as if statements, foreach statements, and a special Layout directive that works similar to ASP.Net's MasterPages.

So now you understand a bit of what my views look like and how they're rendered, we can move on to EFramework.

EFramework was really an experiment to see if what I was trying to do was even possible.. and then I thought it worked really well, so I kept at it.

What exactly does EFramework provides? It provides 2 things:

A powerful routing engine

An HttpHandler class that functions similar to ASP.Net's .ashx Handlers.

So let's start with the routing engine. The routing engine has 3 pattern matching engines

Regex for regular expressions

Plain for exact plain text matches

Simple, used for my own pattern matching that resembles ASP.Net MVC's routing URLs

I'll only cover the Simple type of pattern matching.

Here is the Routing record for the pages of my Blog:

Routing.AddRoute("paged_index",PatternTypes.Simple,"/blog/{page}",()=>{return new BlogHandler();});

"paged_index" is the name of the route, which is passed to the HttpHandler that handles the route.

PatternTypes.Simple is which type of pattern matching

"/blog/{page}" is the pattern to match. It basically says match anything that looks like /blog/* where * is anything, and put the wildcard value into the page route variable

This is a lambda for creating a new HttpHandler. So basically, when a route matches, it will call on this Lambda and expects for the lambda to return an HttpHandler of some sort

The Simple pattern matching is also quite powerful and can do more than simple wildcards. It's aware of how / affects URLs and can do the following:

"/blog/{entryid}/comment/add" This will match anything like /blog/*/comment/add where * can be basically anything but / and when it reaches a / it knows the wildcard is over

Pretty simple. The Get function is called when the HTTP method is GET, Post for POST and etc. RouteParams is a dictionary with all of the route variables in it. So in this case, the route probably looks like

Routing.AddRoute("page",PatternTypes.Simple,"/blog/{id}",()=>{return new BlogHandler();});

And that's for the most part, what makes EFramework good enough for me.

And then there is FSCAuth, what prevents all of you from posting articles on my blog.

FSCAuth was made because I think ASP.Net's authentication mechanisms are a bit too complex for simple authentication scenarios, such as this blog. And FSCAuth is so easy to use and so secure(by default) that I decided to try to sell it. So how does FSCAuth tie into this site?

Well, I use MongoDB for my database (also mainly for learning something new :) ). FSCAuth works by having a UserStore class and a few configuration options set in Global.asax

First the easy part. My configuration looks like this:

Authentication.UserStore=new MongoUserStore(); //set the UserStore to be used
Authentication.SiteName="Last Year's Wishes"; //put into login cookies
Authentication.LoginPage="/login"; //where to redirect to when authentication is required
Authentication.UniqueHash=Config.UniqueHash; //our secret hash
Authentication.CookieHttpOnly=true; //Set HttpOnly property on cookies
Authentication.CookieSecure=false; //set to choose to only transport cookies over HTTPS
Authentication.CookieUseBase=true; //hash the physical path of the application into cookies.
Authentication.CookieUseBrowserInfo=false; //hash in client's browser information to the cookies.
Authentication.CookieUseIP=true; //Hash in the client's IP address to the cookie. Ties the cookie to the client's IP

Now the last configuration thing to do is create our UserStore. This is a direct rip of mine (to show how easy it is to create one)

Even though I created this framework as a workaround because MVC at the time was very experimental with Mono, I found that I rather like my framework. I can see quite a few limitations, but it works wonderfully for small scale websites. I also have not measured the performance of any of this except for FSCAuth, so I'm sure it's not enterprise ready, but for this low-traffic blog, it works really well. And I learned a lot about ASP.Net in building it.

Anyway, hope you enjoyed reading how this site works and maybe are curious about one of my 3 projects. In case you are, here are the links to the projects again:

So I decided Quokforge is a bit too immature for me. There's quite a few bad things about it, including admin intervention for a lot of things.. and the admin is a bit lazy. That, and the implementation is pretty buggy and a bit insecure.

So, while waiting for him to purge my SVN repository of AuthenticationModule.cs, I decided instead to just move elsewhere. So I'm on GitHub now. It's my first time using git, actually, but I like it pretty well so far. Only marginally harder to use than SVN really.

Anyway, the project URLs are EFramework and EView. So go branch or fork or whatever those git people say to do to projects!

And the hyper link helper is easy to create also, and is created from the EView T4 template.

One problem I've just thought of though is that when making a base template, you won't be able to have very good inheritance. This is because EViewRender currently does not call base.EViewRender(). To be honest, I'm pretty sure there is no way to have good inheritance for views. What would the relationship even mean? But nonetheless, you can create base classes so that for instance you could have

Only thing I need now is to implement some helper functions. I'm thinking of going through the basic HTML tag list. One of the more interesting ones will probably be <select> as that will take an enumerable of some sort. Meh, I'll figure it out when I get there :P

Well, I was trying to not tie my website to MVC just for example sake, but I'm basically reinventing MVC the more I get into it. MVC isn't bad, but I'm not convinced it's the cure-all for every website like everyone else does.

Anyway, I could add some really neat possibilities to EView and EFramework by merging the two and making them directly dependable on each other. Well, EView I'd like to keep fairly independent because it has uses outside of the web. But EFramework I think could be a lot easier to use if views were built into it. This would allow me to make a few more assumptions making things easier for both me and the implementors.