Minh T. Nguyen

        "Enemy's Gate Is Down" 		Search this site:

Minh Tri Nguyen Minh T. Nguyen enderminh Vietnamese nguyentriminh blog Visual Studio .NET Tips and Tricks Nguyễn Trí Minh
posts - 203, comments - 798, trackbacks - 120

Overlooked ASP.NET features of Whidbey

I just finished reading "A First Look at ASP.NET v.2.0", which is a great book I recommend everyone who wants to seriously read up on upcoming Whidbey stuff and are just simply tired of seeing the same high-level slides we see to much at Microsoft events. It's a rather expensive book ($40), but definately dives into detail into all new features of this I-wish-I-can-have-this-now release. It's extremely excited about all these new functionalities and controls I can work with.

Forget about master/content pages, generics, partial classes and SQL Server cache dependencies, here are the other great new things that Whidbey will bring that is being overlooked:
   
The MultiView control
  
The ASP.NET MultiView Control is a control consisting of different Views, in which you can define sections of HTML and ASP.NET code that you can turn on and off. Only one View can be active at any given time. What I have done in the past with many ASP:Panels, this single control will have a unified model for me to do this. The MultiView control can be used to generate wizards for instance, but wait... there is a new
   
Wizard Control!!
   
Yippieee, the new Wizard Control allows you to define each WizardStep declaratively and has built-in function to navigate back and forth in the wizard and control the next/previous/finish button appearance. The beauty of this is that the Wizard control allows you to generate wizards without the need of multiple pages. It's all postback on a single page!
   
The Literal Control
   
Ahh, the Literal Control now has an LiteralMode=LiteralMode.Encode attribute that will automatically HtmlEncode all its content. Very neat idea. I was about to write my own Label control that does that and then I stumbled on this. Can we say Bye-Bye to cross-site scripting attacks? No, not entirely, but it definately helps out a lot, don't you think?
   
Panel.ScrollBars
   
Very cool, the ASP:Panel control now has a scrollbars. So, you just define a constant height or width and the scrollbars will appear as needed. The web is really merging with the Windows Forms world more and more, in preparation for Longhorn, I guess.
   
ImageMap
   
The new ASP:NET ImageMap control allows you to define clickable hotspots of an image. This will generate the appropriate html tags for the polygons, rectangles or circles that you can click for a given picture. The cool thing is that you can react to them on your post-back inside a simple switch statement.
   
SetFocus
   
Calling MyControl.SetFocus() will automatically set the focus on that control on the client-side. This will be come very useful when you create forms that a user needs to fill out. No need to write your own javascript onload methods to set the focus to a particular textbox.
   
Cross-Page Posting
   
A new mechanism supports cross-page posting. You can specify per control where the page will post to, and on the second page you can detect that it's participating in a cross-page posts and retrieve data from the previous page through strongly-typed properties (assuming they are public of course).
   
Client Callbacks
   
But in my opinion, the most coolest and most overlooked feature of Whidbey are Client Callbacks. ASP.NET 2.0 will have a built-in feature to facilitate the invocation of server-side methods from client-side scripts. What in the past has been done through complicated javascript http requests, the new feature will allow you to define which server-side method will be called from a client-side script. The server-side method that will in return call a client-side callback function to pass back the results. Sure, this is still a little bit complicated, but just imagine all the possibilities that are now open. You can retrieve data without postbacks, you can invoke a method in the background without postback. I think I should write an article about this. I am so excited and am surprised that this hasn't been mentioned anywhere else other than this book.
   
Dude, I wish I can have Whidbey now (though I still think that the Microsoft folks should take as much time as they need to make this a stable release!).

posted on Monday, March 15, 2004 10:16 AM

Feedback

# re: Overlooked ASP.NET features of Whidbey

I have implemented Client Callbcks using a ServerXMlHttp control, making it somewhat similar to calling a web service. This was more work than I would have liked.
How does it work in Whidbey? Frames are kinda lame, but components are not supported in all browsers (AFAIK). What is the solution? If it is frames, I would probaly stick with my solution. If it is a component, how will it work with non-MS (for my current project I do not care - it is all IE5.5+). If it is some other standard HTML technique what are the details?
My hope is that it is similar to my solution (basically, able to call web services through a component that gets included in IE (and optimized), but a whole lot less work.
3/17/2004 7:10 AM | theCoach

# re: Overlooked ASP.NET features of Whidbey

The way it works in a nutshell is that you call a method provided for you in the .NET Framework class that creates for you the exact javascript-string that is needed to start invoking the client callback.

That javascript-string (that you then just put inside some javascript event) will basically use the XMLHTTP to invoke a server-side web method. The Whidbey framework will then facilitate the call back from the server-side. So, when your server-side method finishes, it will call back a javascript-function that you have predefined.

So, yes, it's still using the XmlHttp post object, but you just don't have to mess with it at all. In addition, you can query through Request.BrowserCaps.SupportsXmlHTTP whether that browser supports this feature or not.

So yeah, it's the same solution, just less work (you don't even need to know what an XmlHttp object is).
3/17/2004 10:46 AM | Minh T. Nguyen

# re: Overlooked ASP.NET features of Whidbey

So this is like the remoting feature that we had in classic ASP? It was a pain then, but very powerful
3/25/2004 6:57 AM | Goudinov

# re: Overlooked ASP.NET features of Whidbey

Sorry, never did Remoting in Classic ASP. ;)

But you're going to love this feature. It really opens up the doors to so many cool applications.
3/26/2004 5:42 PM | Minh T. Nguyen

# re: Overlooked ASP.NET features of Whidbey

You can do all this really easily in ASP.NET as it stands now...just use the Web Service Behavior (IE5+)

http://samples.gotdotnet.com/quickstart/aspplus/doc/wsbehavior.aspx

Just create a web service and then call from your javascript funcion, can be sync or async too. I've used it loads, and it's really easy to impliment once you get the hang of it.

Sounds like Whidbey will make things a *little* easier, but it's not all that hard now to be fair. Combine this with a bit of DHTML Data Binding and you can have really cool looking/responsive apps!

2c.

--
Matt

3/31/2004 3:42 AM | Matt Wright

# re: Overlooked ASP.NET features of Whidbey

So I said that maybe I should write an article about it, and well, I did.

Here it is:
http://www.dotnetjunkies.com/Tutorial/E80EC96F-1C32-4855-85AE-9E30EECF13D7.dcik
5/4/2004 10:55 PM | Minh T. Nguyen

# re: Overlooked ASP.NET features of Whidbey

Would love this feature today. Matt, any sample sources out there other than MSDN links for doing it now with web serviecs? Th ability to ping a db for a recordset of name-value pairs to repopluate a dropdown with out page refresh would be great.
8/3/2004 11:52 AM | Mickey

Post Comment

Title  
Name  
Url
Comment   
Enter the code you see: