
At this website I will create an Ajax Library focusing on server-side bindings to abstract away JavaScript for ASP.NET and
Mono but the lessons learned here will also be useful for others building Ajax libraries. Even if you're doing it towards J2EE, Python, PHP or not even using a server-side framework at all.
If you use the lessons learned here to implement an Ajax Framework for another server-side framework, I would appreciate knowing about it so that I can link to your website where your project recides :)
The end product will be a complete server-side binded Ajax Library for ASP.NET and Mono's ASP.NET implementation working with every JavaScript enabled browser on the planet.
This is the first part where I will write about the initial decisions you need to actively think about *before* starting out.
WARNING!Most of my blogs tend to becomes *VERY* long, though I feel myself that all my words counts and that there is little or nothing I can remove. Think of it like a book though. If you cannot handle reading long texts on a computer then I suggest you print the page out and read it "as a book" since that might be easier for some people. A book is how I think of them anyway.
Use 3rd party JavaScript Frameworks?
There exists a lot of really great JavaScript frameworks out there like
Prototype.js,
jQuery,
Moo Tools and
Dojo Toolkit. All of them are great in their ways as JavaScript Frameworks and will give you a serious boost in the beginning if you choose to build your JavaScript foundation on top of them, but the problem is in their nature. They are
*JavaScript* Frameworks and at least when we're building Ra Ajax we don't really need a great JavaScript Framework. We need the "bare minimum" of a JavaScript Framework since we're creating a server-side binded Ajax library. So by choosing those Framework you will get a head start, but you will also get a LOT of overhead which you really don't need and you especially don't want in regards to download and bandwidth-bloat.
Believe me, I know since when I started out with Gaia Ajax Widgets I spent the first half wrapping around prototype.js and ScriptAculous, and the rest of the time regretting that decision...
So we will start out with our own "custom rolled" JavaScript Framework which will contain nothing but the "bare minimum" needed to abstract away the server-side bindings. This will *significantly* reduce the amount of JavaScript the browser clients will have to download when running code using our Ajax Library.
Support Mono or not?
Many people unfortunately look at
Mono as a "child's toy version of .Net". This is *wrong* and might several years ago have had some truth to it, but today Mono is powering really advanced and great things like the scripting engine of
Second Life,
Unity 3D and many more really great living, advanced and vivid projects. Mono is something we should support since it gives the users of our Ajax Library a choice in regards to deploying their applications on Linux and a pure Open Source stack or "only Windows servers". Most of Mono is also MIT and LGPL licensed which means that if
Novell decides to abandon it, Mono will be INSTANTLY forked and live on as a community project since it by nature enables .Net applications to be running on Linux on a pure Open Source stack. But by choosing to support Mono we also add up some small overhead on our Ajax Library since Mono does not implement everything ASP.NET implements like Themes, ViewStateModeById and has a slightly different model for databinding repeaters and so on. This means we need to at least occassionally TEST on Mono to make sure we're not going down a "blind path". Though this testing is not hard and in fact to support Internet Explorer is way more difficult than to support Mono. Believe me, I've done this before ;)
Partial rendering?
Partial Rendering is a word more or less coined and made popular by
Dino Esposito and probably was invented by
Jason Diamond when he initially created
Anthem.NET which was a HUGE source of inspiration for me when I created Gaia Ajax Widgets. Partial rendering basically means to render HTML within some container HTML element. This is the way
ASP.NET AJAX works and is an easy way to implement Ajax behavior. Unfortunately there are lots of senior Ajax developers who have continously bashed this way of creating Ajax Libraries including Dino at
DotNetRocks.com (podcast) and myself. Another approach is to implement an API on the client-side like for instance
Gaia Ajax Widgets have done. (my first Ajax Library)
This basically works by having a client-side API for the server-side Ajax Widgets which the widgets themselves communicate back and forth towards. This has a very interesting side-effect in addition to significantly reduce the bandwidth. The client becomes STATEFUL!
Statefulness is a Design Pattern which you should avoid in *all other circumstances* but fact is that without a stateful client for your Ajax Library you will be doomed into doing all of your advanced Widget manipulation with JavaScript and the whole idea of abstracting away JavaScript goes completely out the window. The lack of a client-side stateful pattern is the reason why Microsoft are resorting to using weird constructs like WebServices and such to populate their AutoCompleters and so on. So we will not do Partial Rendering in Ra Ajax unless we really have to. This means that when we initially show a Widget we will do partial rendering, and when we are re-creating and manipulating the child control collection of our Widget we will do partial rendering, but apart from that we will never do Partial Rendering!
Inherit from the System.Web.UI.WebControls controls?
Another more difficult-to-understand choice we need to make is to whether or not we will inherit our Ajax Controls from the controls inside the WebControls namespace like for instance the System.Web.UI.WebControls.TextBox Control. This decision took me a year to understand the implications of. By inheriting from TextBox, Label, CheckBox and so on from ASP.NET we get controls that are 100% compatible with the ASP.NET Controls. Unfortunately we also inherit a lot of
LSP problems. LSP problems are also really obscure and they tend to "stack up" and form leaky abstractions which unfortunately have a way of accumulating every time you add another layer of abstraction. In addition the level of
Cohesion in the ASP.NET controls are not very good. So by inheriting from the ASP.NET WebControls you gain some but you will also constantly be at war against the LSP and Cohesion problems inside of the WebControl hierarchy. I know because when I created
Gaia Ajax Widgets I constantly battled the problems from the native ASP.NET Controls. The ASP.NET model is actually quite good, unfortunately the WebControls themselves are not a part of Microsoft's greatest achievements...
An example of such a problem is the fact that the CssStyleCollection class is implemented as sealed and with an internal constructor in ASP.NET. This means that it is *impossible* to override the functionality of it in your core. The way we solved this in Gaia Ajax Widgets was to read the properties of the Style collection property during OnInit of the control and then later "diff" the changes and send those back to the client. Far from optimal in addition to that it made the code orders of magnitudes more complex. In addition when going down this path we also had to add up Reflection to read the other properties since when you have started down the "diff path" you tend to want to continue with one uniform solution. This added runtime overhead for our server which was quite expensive and costed us a lot of development time to optimize. Not to mention that to turn off ViewState effectively becomes impossible.
It is actually easier to implement your own version of CssStyleCollection than it is to re-use the one already existing in ASP.NET.
In addition the WebControls have a lot of redundant properties like BackgroundColor, Font, etc. In fact a TON of properties which you also must track which is nothing more than redundant versions of the Style property keys which makes it not only more complex for you but also more complex for your users since they have "two paths" into the same problem. Always have ONE path where possible. Never implement two solutions where one will suffice.
We will choose NOT to inherit from the TextBox, Label, CheckBox and so on and instead create our own controls from scratch which in fact by experience I know is easier than to think you can re-use the ASP.NET WebControls. This will save us a TON of time battling both the differences between Mono and Microsoft ASP.NET and also battling the lack of LSP and Cohesion in the ASP.NET WebControls.
License choice
Maybe the hardest part figuring out is which license you will want to use. For Ra Ajax I choose the LGPL license which basically says;
"Use as you wish but don't steal the code and close it". The reason why I choose this license is first of all because I have had
threats about being sued by my previous employer which means that I cannot have any financial incentives at all behind this effort. In addition I think that the Open Web is really important and that we need the Open Web to prevail and by choosing a very permissive license for our Ajax Library we're basically making sure of that our Ajax Library will be used by a lot of users.
To not use an Open Source license for a Framework (ANY type of Framework) today will basically not work! Coders are being more and more used to consuming Open Source libraries, and they will want to see the code for whatever they're using. If you don't Open Source your Ajax Library you will probably get *zero* users! This fits at least me perfectly since I happen to love Open Source. Later on if you decide to go "commercial" with your project you will also get to hire the best developers for your company instead of "second class" developers willing to work for Closed Source libraries. The best System Developers tend to be drawn towards Open Souce code! You will also get a lot of publicity simply because you choose an Open Source model! Not to mention that it is
the right thing to do! Innovation should be OPEN, especially the RIA Framework of the 3rd Millennium!
Note that all CODE snippets at this blog is licensed as a pure MIT license, meaning you can copy and paste code as you wish from this blog into your own code if you wish.
Open Standards
Should you follow Open Standards as proposed by the
W3C?
There are three answer to that question;
YES,
YES,
and ...YES!
Without following the standards where possible your software will be outdated before you can count to ...zip...!
By following the standards as given to us by W3C.org you practically have a guarantee that your software also will work in the future. TCP/IP is still here, almost unchanged, even though it was created almost 40 years ago. TCP/IP was created as an Open Standard and because of that software written to use the TCP/IP standard in the early 70s still function. If you choose to build on "some favorite ActiveX component" your software piece is very likely NOT to make it more than 5 years from now. Use Open Standards where possible, and glue in the "missing pieces" completely loosely coupled where you HAVE to. 95% of YouTube is STILL JavaScript and HTML! And even Adobe doesn't use Adobe Flex for their forums! And microsoft.com is HTML and JavaScript, NOT Silverlight!
If you follow the standards where you can it is higly likely that your software will still be here 150 years from now in some form, just like the railroad tracks from the 18th Century across the world is still here today. Because they choose to standardize the track size! And today mostly everything can be built purely on top of the Open Web. Even video and Canvas is coming in HTML5!
Wrapping up...
This was the first blog post in a series of blog posts where I will try to completely walk you through the process of building an Ajax Library, focusing on ASP.NET and
Mono. When I finish this series we will have created an entire Ajax Library, bottoms up. And you will have access to all the information needed to reproduce the Ajax Library yourself.
Feel free to subscribe to my blog by clicking the yellow RSS icon at the address bar of your browser to get to the URL. Also if you register at this website which can be done at
the forums section I will send you an email every time I write up another blog. Sometimes I will write about other things to "fill in the blanks" or because I am dedicated to also other aspects in life then just Ajax Libraries, but all my "Create an Ajax Library" blogs will also be sent to you then.
At the end of this process I might even wrap up the stuff and put into a book or something, but I really despise dead forrest distribution, so it'll probably be licensed under the
GNU Free Documentation License or some
Creative Commons ("Some Rights Reserved" license) for your convenience.
Until next time, have a nice day :)
Thomas Hansen
Comments