Posted on 10/31/2007 10:44:00 AM by Justin Etheredge
By now most of you have probably already heard about the MVC framework that Scott Guthrie announced on his blog about two weeks ago, and if you are anything like me, then you are elated that this is happening. While some other, like the castle project, have already been here before, it is nice to see that we will have a full Microsoft backed framework that we can sell to our places of employment. So, if you are one of those people who has read up on Ruby on Rails, Agile Development, MVC, and thinks that getting rid of the viewstate will be the best thing since sliced bread...then you can stop reading now. Sorry, this post isn't for you. This post is for all of those asp.net developers out there who have heard about that MVC thing, but haven't quite got their heads wrapped around it or for those who mistakenly think that the asp.net framework already implements an MVC pattern. Continue reading the rest of this post...
Posted on 10/31/2007 12:13:16 AM by Justin Etheredge
Starting tomorrow I am going to start a short semi-daily post which is going to be called "Tag a day". Since, as most people know, asp.net developers don't actually write any html we need a little practice when it comes to new standards like HTML 4.01. Seriously though, wasn't HTML 4.0 enough? But anyways, in order to help the common asp.net developer I am going to post one new html tag each day and describe what it is used for. I'm not going to be posting up silly tags like <a> or <p> that we all know how to use. We do all know those, right? Well, if not, then please send me a note by the contact page and I'll post something up. Don't leave a comment though, you may be laughed off the internet. If the tag a day posts are successful enough, then I may also do a CSS tag a day when I am finished.
Posted on 10/30/2007 10:45:14 AM by Justin Etheredge
I'm getting better at inflammatory titles, don't you think?
I know that I will probably get some flak for saying this, but I really do not think that proprietary plug-ins like Flash and Silverlight are the future of the web. While I do believe that they have their place in the Internet ecosystem, I don't believe that they are going to be the future solution for developing web interfaces. Adobe has made some big strides with Flex and their recently introduced AIR, which takes web application back offline. Microsoft has put a huge amount of work into silverlight, even creating a mini-clr that they are building into Silverlight 1.1. The tools will most certainly be there to create these rich internet applications, but are people going to accept more closed formats at this point?
One the problems is that they are trying to bundle the display technology together with the back end programming model. This approach allows to them have a richer, more integrated development experience but this is also what holds them back. HTML had many reasons for succeeding and one of which was its simplicity. The HTML spec merely defined a document and how it was to be displayed (this has now been superceded by CSS but the spec still lets you defined visual style in HTML) it was not tied to any back end technology and it didn't require any fancy tools in order to create it. At the time HTML pages were all static, but it was quite easy for computer programs to generate these simple files. (Parsing and rendering them is a completely different story) Since it was so easy to render these files it was no time before it was happening everywhere and since HTML was just a file spec, anyone could do it. HTML cemented the trend for an open, interoperable internet and now it seems like companies are trying to reverse that. But don't be fooled, these closed standards are far from the only competitors on the block, check out some of these open and closed options below.
XAML: Microsoft has made XAML a standard, but it is anything but open. If Microsoft completely controls a standard then a large portion of the developer world will never embrace it, no matter what. And you may be asking, but I thought you just said that Silverlight is not the future of the web, well, XAML and Silverlight are not one in the same. In fact, XAML can be used without any supporting back end technology as it already has been with eFace. XAML is merely a way to represent interfaces, or really any vector based objects using its XML based markup. Microsoft has invested considerable resources making sure that XAML has everything it needs in order to build rich interfaces. Considering it is the display technology behind Vista, lets hope they got it right.
XUL: Some of you may have already heard of XUL. It stands for XML User Interface Language. It is a standard that was developed by Mozilla and has been implemented in Firefox. While the XUL Spec is open, its only full implementation is in Gecko (the rending engine for Mozilla browsers, including Firefox). The XUL 1.0 spec was created in 2001 and as of now it appears that XUL 2.0 is still on the drawing boards. Whether or not this will ever catch on outside of Mozilla is still waiting to be seen, but currently there does not seem to be any push to make this happen.
SVG: SVG stands for Scalable Vector Graphics and does pretty much what it says. It is an XML based format that is designed for displaying 2D graphics in vector form. The original draft of the 1.0 spec was released in September of 2001 and the 1.1 spec was released about 2 years later. While Opera, Gecko, and Safari (in Safari 3) all have support for SVG, Internet Explorer does not and it appears that Microsoft has no plans to support it. This could be a significant stumbling block for this every becoming a valid platform for building interfaces.
SMIL: SMIL stands for Synchronized Multimedia Integration Language (with a sexy name like that, it is amazing it hasn't caught on </sarcasm>) It is XML based and is more of a complementary technology for HTML or SVG. It allows you to define animations, shapes, timelines, etc... It is very similar in this sense to something like Flash or Silverlight. As of current writing SMIL has been integrated into Quicktime, some other lesser known media players, and (according to Sonic Solutions' white paper) forms part of the engine that drives HD-DVD's menu system. According to what I can gather from several searches, Gecko also supports a good deal of the SMIL 2.1 spec.
Canvas element: This is probably the reason why Safari didn't get support for SVG until Safari 3. Apple decided to implement their own way of displaying vector graphics and included the Canvas element into Webkit (which is the project behind Safari). The canvas element has since made its way into Gecko and Opera but has no support in Internet Explorer. Since the canvas element is now part of the HTML 5 spec, Microsoft will most likely support it in a future version of IE, even though they are mum on supporting HTML 5 currently (Come on Microsoft).
CSS Transforms: The latest entry (and the post that sparked this post) is CSS transforms from Webkit. While I have not played with them yet (I'm not in the habit of downloading Webkit nightly builds just yet) it appears that they allow you to transform (scale, rotate, etc...) other html elements using CSS. While this may not have the full 2D drawing capabilities of some of the above solutions, it may end up being part of a larger picture. As history has taught us, people are more likely to accept technologies that build on what we already know that those that completely throw away everything we have done before. Unless of course your old technology sucked and you are dying to get rid of it. For example COM and ASP classic. (before I get yelled at, this is *mostly* a joke)
So, as you can see, there are many projects going on currently that are all vying to become the next technology to help us begin to render more rich interfaces on the web. While some of these technologies may only be part of the solution, in the end lets hope that the market decides which ones are the best. But in the meantime we will just have to deal with our html, css, and javascript playground. (Even if CSS 3 is NEVER coming out. Or XHTML 2 either. But that is a discussion for another post.)
Also, before I start being accused of being anti-Flash and anti-Silverlight please keep in mind that I believe that these technologies definitely have a place on the web. Just look at YouTube, none of that would have been possible without Flash (or a similar technology) because audio/video plug-ins/codecs are currently not standardized in the browser. Creating a cross platform solution for audio and video was hard enough the likes of Adobe and Microsoft it may be a while before we see a cross platform open standard emerge. (And yes, I do realize that Adobe opened up the Flash spec, but they explicity state that you cannot use it to create any competing free technology. So I would not really call this an open standard either.)
Posted on 10/29/2007 10:59:00 AM by Justin Etheredge
How is it possible that I have never heard about SubSonic before? SubSonic appears to be a very full featured, template driven DAL generator. It all started yesterday when I saw this post on Phil Haack's site about Rob Conery joining Microsoft and I followed the link to Rob's website. Which, in turn, led to the embarrassment that was my last post. But it also led to me discovering SubSonic. So in retrospect I believe it worked out in my favor (In your face karma!). I have been watching a few of the Sonic Casts and I have to say that I am going to have to delve into SubSonic deeper on some projects in the future. And now that I know that Microsoft has hired Rob to work on integrating SubSonic with the MVC framework coming out, it gives me even more of a reason to try and play with it in the future.
After watching Sonic Cast #2 I am going to have to say that I like Rob already. Not only does he not have an annoying voice (which is hard to find these days in the world of Pod/Webcasts. You won't find me doing any of these!) but he speaks slowly and clearly and doesn't like the ObjectDataSource!! I know I just threw that one in, but in the second Sonic Cast he starts to go through the paging features of SubSonic using the ObjectDataSource and at that point my mouse cursor was inching closer and closer to the close button on the window. Then he finishes it up and I say to myself "well, there sure is a lot of time left on this video, what is going to happen next?" And he gets on his soap box and says how he doesn't like the ObjectDataSource and how he prefers to use the code behind to bind data directly to his views. I mean, look at this. Now this is a real man's databinding (is that an oxymoron?).
The really cool stuff came when I started watching Sonic Cast #3 which was about the MVC patterns that they have added to Subsonic. In the webcast Rob started talking about how SubSonic generates the Models and Controllers, but then on code behind of the page you must access the Controller to pull data for the view. This isn't really what an MVC pattern is, in fact, in the webcast Rob said that this is more of a Data Broker pattern than an MVC pattern, but that is because asp.net by default implements a Page Controller which controls all flow of logic in the pages. So, without sounding like pattern regurgitating moron, the Controllers are setup similar to a Data Access Object and then the classes now represent the Domain objects which have no knowledge of the mapping to the database. The difference is that the Data Access Object in this instance should contain logic related to the flow of the application but this is hard when asp.net is forcing all of the logic to the page.
But then again, that is exactly why Microsoft hired Rob. The new MVC framework that Microsoft is going to soon (soon being relative) release is the key to filling this gap (or actually replacing the gap altogether) and they are hiring Rob to make sure that SubSonic works with it. It seems like the developer side of Microsoft has been on a roll these past few months, hiring Rob Conery, hiring Scott Hanselman, releasing the source for the .net 3.5 framework, announcing the MVC architecture and just generally seeming to really be starting to understand the community. Or maybe certain people have always understood the community it is just that these people are being put in right places to exact change. (Then I see articles about Steve Balmer and his comments about open source and I feel like I am dealing with Dr. Jekyll and Mr Hyde.)
Posted on 10/28/2007 3:39:58 AM by Justin Etheredge
I read this post over at Rob Conery's site and I thought I would go ahead and post this since I would look like a copy cat no matter when I posted this now. The article is questioning whether or not we really need to separate our code and markup. Basically it is asking the question about whether inline scripting is okay. And in my opinion, I think it is... but as always this point needs to be fleshed out (and of course I don't flesh it out anywhere near as much as Rob did).
The idea of separating code and markup in html came from the good old asp days of writing a huge application with a ton of code in the html. Code that often had nothing to do with the actual rendering of HTML. Those were the days of SQL queries spread all over the place, COM objects, and just general chaos. And so now we have a code behind file, which is all fine and great, but what happens when we actually follow the true tenants of n-tier design? The code behind becomes this super lightweight file that contains very little value. If you are truly trying to abstract your business layer (especially in something like an MVC architecture where your code behind won't even be controlling the logical flow of your app) then any code in the code behind should be solely dealing with hooking up your business layer to the display. So why can't this small amount of code go into the html?
In fact, in some instances it seems that it would make things easier. Say I want to spit out a table with a bunch of names in it. Using the traditional asp.net model we would drop a repeater in the markup, make a template for the header, footer, item, and alternating item. Then we would inject our data binding statements into these templates and go to the code behind to wire up the DataSource or just put a string in the DataSource attribute to load our objects. (I prefer to hook up the data source in the code behind so that I can have compile time checking on it.) Our only other option would be to put a literal on the page and just spit out the html from the code behind, but this makes the code even less readable. So lets say we do it the asp.net way and by the time we are done, it all looks like this...
Now all of that seems like it didn't really take all that much work, but look at all of the cruft we have injected just to do something that could look like this...
Look at that. Beautiful. I don't have viewstate to worry about, I don't have a bunch of other tags that aren't html, I don't get any ridiculous asp.net generated ids, I don't get any random html spit out by asp.net controls (in this case I wouldn't anyways), and all this *with* compile time checking.
Now I am the last person that ever wants to see people injecting business logic or sql back into their web pages, but this actually still *looks like* html and we are web programmers, aren't we?
P.S. I am excited about the asp.net MVC framework. :-)