My first look at "Atlas" (http://atlas.asp.net)
At last Microsoft has released an early build new AJAX libraries based around version 2 of their .NET Framework.
Skip this next section if you are already familiar with what AJAX is and don't want to read my lame ass description of it.
The most basic intro to AJAX…
Essentially AJAX is Asynchronous JavaScript and XML. At the core of it all what you get is the ability to use JavaScript to talk to the server asynchronously (meaning behind the scene in your pages, without tying up the interface).
A practical example would be if you had two Combo boxes. Country and State. You drop down Country and State automagically populates with the appropriate states for the chosen country, of course this happens without pre-loading JavaScript on the client, nor doing a post back to the server directly.
Typically at the core of any AJAX library we see something along the lines of first creating an instance of the ActiveXObject "Msxml2.XMLHTTP", and then using it to make the calls back to the server, asynchronously. Don't be afraid when you see "MSXML", see this post regarding cross platform support. Once the call has been completely the library usually bubbles the event back up to the method you state.
For more details and a 100x better description see this doc.
So now you know what AJAX is, what do I have to say about it...
I have taken the time to quickly review the QuickStart and the core Atlas Documentation. http://atlas.asp.net/quickstart/ http://atlas.asp.net/docs/default.aspx
I don't want to cover everything that is stated in both those documents you can read them if you like. I intend to just cover the highlights and give my thoughts on what I'm seeing.
OOP:
So the first thing we see is the fact that Microsoft has put allot of thought into the OOP aspect of programming (thank god!). We see that we get some tools for allowing Namespaces, Inheritance and Interfaces. You can literally register namespaces with the Type system on the client setup a class hierarchy and even implement interfaces. The syntax looks a bit strange but I'm sure we can adapt.
ASMX Support:
Next we see that they have enabled the whole ASMX Web Services goop to be easily accessible for us. Simply create your ASMX Web Services as you normally do, and then use <atlas:Script> blocks to include the common JavaScript libraries including the AtlasRuntime.js. I'm sure those includes will be cut down to one prior to RTM. I cant see any reason why we would need to have 3 JavaScript "include" blocks just for Web Services support or for simple AJAX support on the client, let the server determine and control exactly what support JavaScript it needs to pump out.. I immediately notice that their default library script is approx. 137KB, not sure if that is a very reasonable size but time will tell.
What's cool is this next line:
<script language="JavaScript" src="SimpleService.asmx/js">
Notice we simply need to point it to our same old ASMX service with the /js modifier on the URL. Here is the full URL in their help doc for the output of the "SimpleService.aspx/js". Notice it is simply emitting JavaScript out of the service. It would seem logical that the src attribute of the script tag above can be any sort of fully qualified URL, including offsite url's, but I don't see that stated anywhere in the help. Also, it would be nice to see some sort of a wrapper for non .NET services, to automatgically wrap up a simple WSDL with the appropriate JavaScript. Maybe they could add a /out:js parameter to the WSDL.exe command itself? We then could simply include that script as our source instead of the .asmx/js directly. If they don't enhance the wsdl.exe tool directly I would be willing to put money down that someone in the community will have a tool publish in the coming months prior to actual RTM.
Serialization:
As we expected, we can send and receive complex types via this toolkit. I wonder what serializer is used. The SOAP Serializer seems obvious for those calls to an actual Web Service endpoint, but what about non-Web Service endpoints? I hope we can just use typical/raw XML with out the SOAP bloat (envelope, body, etc). For SOAP Envelope's do we also get header support? Oh, I don't see any example of getting nor setting data with a DataSet. I bet you that this will be baked in as well. I personally limit my use of DS's but MSFT has pushed them onto us so much that most people do use them and you can expect support for them.
Caching data received from an ASMX's seems pretty obvious. Do it on the server as we normally have done in the past.
DataSource:
Exposing a DataSource for Atlas to consume is as easy as pie. Take a look at the examples, some really amazing stuff going on there. Setup your service to inherit from "DataServer", implement the required methods; add the atlas:DataSource control to your page, point it to your DataService (asmx); add some control (for example a atlas:ListView control) and point it to your DataSource then wire up the events like click and such. A simple three step process to wire it all up, now that is what I like to see.
ASP.NET Atlas Controls:
This is where things start to go downhill. It would appear that the Atlas team has invested in an extensive library for markup of our client sided forms. The sections of code marked under "<script type="text/xml-atlas">" and "<script type="text/xml-script">". I personally don't like this direction. What are they thinking!? Currently, we have an object model for markup and event handling for controls on the server and now they want to add a completely new model for the client?!
Why could we simply not take advantage of this "runat" attribute on our server sided controls and let the framework put it all together for us? runat="client"
I understand that this stuff is (probably) not going to be included directly in the framework, v2, and will be shipped as a separate install, but come on guys! Another completely separate Object Model? Is that really necessary? How many will actually use this? Is there plans to actually include it in v3 of the framework?
With the coming of XAML we will see yet another object model. That brings up my next point…
My style of Adaptive Rendering…
I have a great idea, which I stated many times already. Let's leverage this whole .NET Framework thing and create rendering engines. That is, this now called "adaptive rendering" we see in v2 for Web and Mobile controls, let's extend that right out. Have a single set of controls which us hard working developers need to learn and Microsoft, you build us rendering engines for each platform: Web, Web+AJAX, Mobile, Windows Forms, etc. If someone hits our URL with a XAML browser (essentially a Windows Forms client) render for that request. If they hit with Netscape 2, render old school Web, etc. I hit with IE7, render for it. Let's avoid tacking yet another object model into the mix.
Server Class Library:
First thing that stands out is the Microsoft.Web.Services.Converters.DataSetConverter. As I suspected it looks like they will be baking in some support for DataSets. Along with that it appears that we will be able to create our own Converters, just based on the Microsoft.Web.Services.JavsScriptConverter. Nice to know.
Here we get to see all of the control classes which are currently exposed to the client. Nice big list, unfortunately its an entire new set of controls we will have to learn. Boo!
Browser Support:
What I would like to see as another final deliverable is a cross browser support matrix. I want to know exactly which feature is and is not supported on each and every (semi)popular browser on the market today, their versions and on alternative OS's. Scroll down on this page to get an idea of what I would expect. I think if MSFT really wants the industry to adapt this technology they will need to prove that it has a wide support base in the industry. Given this matrix it would allow us to really narrow down our browser/OS targets and enable us to make a more educated decision.
2 Comments
Comments have been disabled for this content.
Rick Strahl said
Hi Rob,
I kind of with you on this. I'm really stoked about the core functionality, but I'm skeptical of the control architecture bit. But maybe it's too early to tell and I haven't had much time to check it out.
As to a single model - I think that's never going to happen. There's too much of a mismatch between supported features. Look at just the mobile control integration which by comparison should be very easy and MS didn't manage to get that into this release either. The problem is how do you abstract something like XAML that will have rich placement behavior vs. HTML which in most cases does not. Or worse degrade down to mobile.
I for one rather have a complete model that gives you access tot he full range of features vs. a watered down model that can't do anything useful when the power is there...
Baines said
Very great post. I just stumbled upon your weblog and wished to say that I have truly loved surfing around your blog posts. After all I will be subscribing to your rss feed and I hope you write once more soon!