Beta 2 first impressions

Breaking changes were all in the transition from July CTP to Beta 1. Now the just released ASP.NET AJAX Extensions Beta 2 proceeds on the same path delineated with Beta 1 and is pretty easy to work with.

All the information in the release notes was enough to adapt Beta 1 code to the new build. No worries; everything's smooth and seamless.

The significant news is that Beta 2 is virtually feature-complete. I don't know when it is going to ship as a  v1.0 product, but what's in at this time is really close to the final shape.

Summarizing, ASP.NET AJAX Extensions 1.0 will feature:

Partial rendering through UpdatePanel control and friends (including UpdateProgress, triggers, and Timer).
You can now link a progress template to a given update panel and client-side events are fired to the page during the set up of the panel refresh. This feature is invaluable as it makes possible for you to adjust the UI (i.e., disabling/enabling/graying controls) before, during, and after the refresh

Web service client calls
You can invoke ASMX local Web services. Bridge files and cross-domain services will be back in future post v1.0 builds although they'll take a significantly different form and syntax. For now, if you want to call a remote Web service (say, Amazon) you have to do that the old way using a server-generated proxy class or, in case of plain-old XML interfaces, also the WebRequest managed class would work. Page methods are to be static which mostly means that you can't access page controls. To me, it's not a big deal.

Extenders
Although the AJAX Control Toolkit is still a separate entity and download, base classes for building extenders are in v1.0. This means that you can safely create your own custom extenders and/or import extenders from the Toolkit. But, again, the toolkit is a separate assembly. And--to the level of knowledge I have at this time--I invite you to be careful with extenders in the toolkit. At least months ago, in July CTP build, I had troubles with the most complex of them and could hardly have them work outside of the provided samples.

Sorry for being repetitive writing more or less the same ideas over and over again. I'm just trying to clear my mind and clarify things before starting on a new book v1.0 book project.

 

Posted by despos | 0 Comments
Filed under:

Headed off to DevConnections

I'm getting ready to meet the 5,000 of you attending DevConnections next week. WOOOOOOW

In spite of what I did for the largest part of the past months, I won't be presenting about ASP.NET AJAX at the show. And given the breaking changes with Beta 1, that is a big relief for me :-)

Instead, I'll be presenting about patterns for an effective, professional and extensible middle-tier focusing on ASP.NET presentation layers and w/o SQL Server. In particular, I invite you to take a look at the following CodePlex project: Northwind Starter Kit.  

It shows a DAL based on industry standard enterprise design patterns and the Northwind database. Inside of the download, you also find a sample presentation layer for WinForms and WPF using the Model-View-Presenter approach. Something that ASP.NET developers should start getting familiar with as soon as possible.

At DevConnections, I'll also have a half-day seminar the Monday (November 6) on rich custom ASP.NET controls developed without ASP.NET AJAX. Benign script injection, hidden fields, and little known server-side control interfaces are the bread and butter of the session. Come and see.

 

Posted by despos | 0 Comments
Filed under:

ASP.NET AJAX--Two weeks later

I spent the past ten days working on Beta 1 of ASP.NET AJAX Extensions. (OK, I also played a bit of tennis but that's another--and sad--story ...) 

I'm just curious to see what's coming out with Beta 2 of ASP.NET AJAX Extensions.  

I'll nimbly bypass the side effects of the breaking changes and cuts in Beta 1 vs. July CTP. Today, I can say that most of the troubles and frustration I encountered along the way was due to lack of knowledge and understanding of the new behavior of old things. Actually, porting old code to Beta 1, aside from dropped features, was a matter of a few hours. The Beta 1 is not more bugged or unstable than any other Beta version. Quality is certainly not the point here. And this is different from what I posted earlier.

My Atlas book is stillborn and was pulped as an old book right off the press without even seeing the shape of a bookshelf. I'll work on a new version starting next week.

So my position regarding Beta 1 is somehow changed after a few days of work with it. In addition to lack of knowledge, objectively certain features have been implemented according to a philosophy different from the one that seemed emerge out of previous CTPs. I complained about the product being unstable; I have to admit that there was much of personal disappointment with that as well as a lot of frustration for undocumented features.

One good thing about Beta 1 and successive
The framework contains EXACTLY what people need at this time and stage. Updatable panels easy, really easy to integrate with existing applications. The possibility of making remote procedure calls, though with some care. These features work great.

One bad thing about Beta 1 (but not necessarily successive builds)
The return of JavaScript and the elimination of neat programming features (from ErrorTemplate to just a bit of XML Script). It seems to me (repeat, me) that the team opted for the solution that required less coding on their own or, maybe more likely, for the solution that can give the maximum of flexibility to developers. Either way, there's the bold return of JavaScript. Not necessarily a bad thing.

To continue in another post ...

 

Posted by despos | 0 Comments
Filed under:

Don't call it Beta 1

I really don't like AJAX Beta 1 and probably will wait a few weeks/months before updating books/classes and whatever.

I don't want to question changes. But timing. Why Beta 1 now? The July CTP was a pretty good one and ready for Beta stage. What we have now is a brand new start and is probably less than a stable alpha. So again why now?

Not to mention the confusion generated by having two versions of AJAX--Beta 1 and value-add CTP. I can't just make sense of this and the strategy behind it. Just wait and see.

Which version should I study and teach? Both?
Which version should I recommend to clients and which to implement?
What if I have sites using July CTP? I feel comfortable only with Web services and UpdatePanel stuff

XML Script and page method don't work in my pages--it could just be me but this is a fact as of today. A lot of ugly JS code is being injected in my pages and should be programmed instead of XML Script. Really hope to be deadly wrong here ...

My guess is that A LOT  of this stuff will dramatically change in the near future. So I won't call it a Beta and still wonder why now ...

 

 

 

Posted by despos | 0 Comments

Careful with Web Services in ASP.NET AJAX

I've never been a quick learner student since high-school. It always took me time to figure out things, tell pros and cons apart of any technology or topic. So when ASP.NET introduced Web services -- sure MS didn't invent Web services, but I'm not sure it would have been the same had ASP.NET not fully supported Web services <g> -- I promptly picked it up the wrong way. For quite some time, I perceived Web services as a smart way of building BLL and make it remote with no significant effort on my own.

Then friends and colleagues explained the right way to look at a Web service. Can you see the "service" in it? Is there any "service" in it? Web is just the transportation layer. Oh cool... thank you.

So what about ASMX Web services in ASP.NET AJAX?

They're ASP.NET Web services, although local to the same hosting application. And they seem to suggest they're a way for you to call into the back-end of the application. Yep, just your BLL.

From an AJAX perspective, ASMX Web services are to be a simple facade to route calls to proper BLL after a proper filtering. It is worth noting, in fact, that AJAX Web services have no security layer around. And any security layer you might want to consider would make AJAX apps complex and cumbersome and anyway sending packets via clear text unless HTTPS is used.

AJAX applications using ASMX web services should consider the following:

  • Use ASMX as a facade pointing to the real BLL -- the critical part of it at least -- only after due checks or through a weak account.
  • Use ASMX to point to UI-level BLL -- that is, the security neutral part of it. For example, methods that return products catalog but not methods that verify credit card or start checkout procedures
  • Do not use ASMX for security critical postbacks, but resort to UpdatePanel controls

There's more, though, about ASMX in ASP.NET AJAX applications.

 

Posted by despos | 0 Comments
Filed under:

AJAX in Austria next week

I'll be teaching in Wien next week.

Solid Quality Learning is pleased to offer a special Atlas night, Thursday Oct 12. Full details here (in German).

See you then

Posted by despos | 0 Comments
Filed under:

Back again

It's been a while since my last post, but I'm in the blogsphere again.

When I did it, I was relatively new to Atlas. Can you believe that? Ages ago :)

I spent last 5 months writing and even teaching Atlas stuff. The final result is a book for Microsoft Press, due out in November. The title is "Introducing ASP.NET 2.0 AJAX Extensions". Yes, we've been lucky (just lucky, trust me) to ship to printers late enough to rework the cover and even remove a few occurrences of the now meaningless word "Atlas" throughout the text.

The book covers all key (and hot) topics of Atlas, including Web Services and remote procedure calls, client-side data binding, Web Service bridging, gadgets, UpdatePanel and partial rendering. Source code and text are as up-to-date as humanly possible. Readers, though, will receive online updates should the text in the book prove clearly outdated sometime soon.

Check it out, and don't hesitate to ask questions if you have some. The TOC is below:

  1. Building Blocks of Ajax-style Web Applications
  2. Building Blocks of the Atlas Application Framework
  3. Updatable Page Fragments
  4. Atlas Control Toolbox & Behaviors
  5. The Atlas Client Library
  6. Web Services
  7. Client-side Data Binding
  8. Atlas Gadgets

Hey, I forgot to say that you can get a sample chapter from the MS Press web site or from the Telerik Web site. I'd love to spend a few words on Telerik asn maybe other great vendors of Web tools, but I will make it in another post to share some high-level perspective on Atlas development.

Have a nice weekend.

Posted by despos | 1 Comments
Filed under:

Atlas and the page methods

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

Posted by despos | 27 Comments

Atlas and the viewstate

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.

Posted by despos | 24 Comments

It's Atlas time in Nice

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 :))

Posted by despos | 11 Comments
More Posts Next page »