May 2006 - Posts

Atlas and the page methods
12 May 06 11:22 AM | despos | 30 comment(s)

At DevConnections, I presented a session entitled "The Atlas Framework--The Big Picture" where I first explained the background of the Ajax lifestyle and the motivation for Atlas. I then finished off presenting a couple of examples--how to call a Web service from an Atlas page and how to invoke a page method.

It is interesting to see how page methods work internally.

A page method is an inline method decorated with the [WebMethod] attribute and placed inside a server-side script block of type C#/VB.

 <script type="text/C#" runat="server">
   [WebMethod]
   public string RetrieveMoreInfo(string id) 
   {
       return RetrieveMoreInfoInternal(id);
   }
</script>

To invoke this method from the client, you need the following Javascript code:

function GetMoreInfo() 
{
    PageMethods.RetrieveMoreInfo(
            document.getElementById('cboEmployees').value,      
            OnComplete, 
          
 null);

    return false;
}

What's the PageMethods object? And who created that? PageMethods is a Javascript object declared in the HTML source. The Atlas server-side framework provides for the following code. To see this code, you just open the View Source window of your browser when the Atlas page is displayed.

<script type="text/javascript">
var PageMethods = new function() {
   var cm=Web.Net.PageMethodRequest.createProxyMethod;
   cm(this,"RetrieveMoreInfo","id");
}
</script>

When the user triggers the above GetMoreInfo Javascript function, the HTTP request contains a couple of extra input fields added by proxy method. They are __serviceMethodName and __serviceMethodParams. Here's a typical request:

POST /Atlas/Postback.aspx HTTP/1.1
Cache-Control: no-cache
Connection: Keep-Alive
Content-Length: 478
Content-Type: application/x-www-form-urlencoded
Accept: */*
Accept-Encoding: gzip, deflate
Accept-Language: en-us,it;q=0.5
Cookie: .ASPXANONYMOUS=M ... s1
Host: localhost:2471
Referer:
http://localhost:2471/Atlas/Postback.aspx
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; Avalon 6.0.5070; WinFX RunTime 3.0.50727)
UA-CPU: x86

__serviceMethodName=RetrieveMoreInfo&
__serviceMethodParams={"id":"5"}&
__VIEWSTATE=/wEPDw ... EtV

This request is intercepted by an Atlas-specific HTTP module, named ScriptModule. The HTTP module kicks in immediately after the handler for the request has been found. If this handler is a Page class--that is, the request is directed to a page (as opposed to a Web service)--the HTTP module registers its own handler for the PreRenderComplete event.
In turn, the PreRenderComplete event code registers a render method delegate (a custom piece of code that runs during the Render method). This code retrieves the method name and parameters, does any due deserialization, and invokes the page method via reflection.

Everything else works just as usual.

NOTE: These details may change in future builds of Atlas

Atlas and the viewstate
09 May 06 10:30 AM | despos | 24 comment(s)

Virtually any ASP.NET developer has a love/hate relationship with viewstate.

On one end, developers love it because it makes programming much simpler and, I would say, natural. You have a server textbox and set it to a value; the textbox morphs into a INPUT tag and users change its value; when back on the server, the same textbox reflects changes and maintains the same settings not modified through the client interaction. This is just great--and would be just impossible without the viewstate.

On the other hand, viewstate easily clogs the bandwidth as it can reach important sizes also for relatively simple pages. For these reasons, viewstate is often smoke in the eyes of Web devs. However, thanks to a new serialization format the size of viewstate is reduced by about 50% in ASP.NET 2.0--without requiring ANY change on your side.

What about Atlas? As of today, when you make a page method call through Atlas the viewstate is packed and sent across the wire. Most of us complain because of the extra burden and because--some say--Ajax.NET doesn't do anything of the kind. I met Bertrand LeRoy at DevConnections in Nice and reminded of this old-but-still-valid post on the subject of viewstate in out-of-band calls.

Viewstate is necessary because it allows you to insert your out-of-band request in the track of traditional postback requests. In this way, you get all server-side events up to PreRenderComplete and more importantly you get "changed" events.

All in all, I believe that while it may be fine to receive "changed" events, I would return all of them for a pinch of more speed in the roundtrip. Subsequently, my hope is that in a future build Atlas will allow us to decide whether to bring viewstate back and forth. I wish the viewstate inclusion become optional and disabled by default. What I heard from ScottGu and Bertrand is highly encouraging.

It's Atlas time in Nice
02 May 06 07:00 PM | despos | 11 comment(s)

It was pretty nice in Nice last week where I've been speaking at DevConnections Europe. I've been quite busy giving ASP.NET, VS, and SQL Server presentations that I barely found ten minutes to chat with ScottGu about Atlas and its brilliant future. I confess I was a bit skeptical in the beginning, but I admit that the guys on the team are just perfect in solicitating feedback and well receive it.
Atlas is slowly but firmly evolving into something that looks like an extension of, and the "next-big-step" past, ASP.NET 2.0. Less focus on Javascript, more attention to controls.
I don't unveil any secret if I say that Atlas will take the lion's share in the next ASP.NET platform coming with Orcas or around that. But we should have a released Atlas add-on a long before Orcas.

Some people here at the conference asked what I feel to recommend to do NOW. Pretty easy job.

I do recommend to learn as much as possible about ASP.NET 2.0 internals. For example: handlers, modules, providers, lifecycle, script-oriented API around the Page class. To learn as much as possible about best practices for control development.

In this regard, I wrote quite a few articles for the ASP.NET DevCenter in the past months to form a sort of crashcourse on control development.

And at Solid Quality Learning, we've just completed fresh new courseware for advanced ASP.NET developers aiming at Atlas and friend technologies. I'll have more to say on this soon. For now, pay a visit to SQLU. (It's free :))

More Posts