Rick Strahl's Weblog  

Wind, waves, code and everything in between...
.NET • C# • Markdown • JavaScript • Angular
Contact   •   Articles   •   Products   •   Support   •   Search
Ad-free experience sponsored by:
ASPOSE - the market leader of .NET and Java APIs for file formats – natively work with DOCX, XLSX, PPT, PDF, images and more

Some Ajax for .NET Tool Thoughts


:P
On this page:

I did my Script Callbacks and Ajax session yesterday at the Portland User Group which was a ton of fun and well received. Attendees had lots of questions both on the technology itself and the various implementations. There seems to be a huge amount of interest in this technology yet I heard a lot of comments at the end that they were glad I showed a lot of different examples that demonstrate a few useful things to do with the technology.

 

It also got me thinking about the current state of affairs. My session was long (what else is new <g>) as I went over Script Callbacks, showed a custom implementation for 1.1 of my own called wwHoverPanel that’s used primarily for retrieving content from a URL and display it as pop overs as well as supporting URL based content retrieval with callbacks for 1.1. Finally I showed My.Ajax.Net from Jason Diamond, which I really like a lot because it’s simple and provides a combination of Script Callbacks in ASP.NET 2.0 and the best features of Ajax.NET. Frankly I think it’s a much better implementation than Ajax.NET.

 

But this begs a few questions: 3 different approaches – which one is best???  Brock Allen and Bertrand Leroy (in comments) raise some of these questions in this Blog entry:

 

http://staff.develop.com/ballen/blog/CommentView.aspx?guid=c35c43f6-5686-40ee-9752-8095a848d821

 

As for me I think that right now there are at least two scenarios that are complementary to each other:

 

  • A page pipeline based engine (like Script Callbacks and My Ajax.NET)
  • A Url based engine

 

Interestingly enough the popular  Ajax.NET from Michael Schwarz falls in neither of these categories as it avoids the Page Pipeline completely and uses a custom HTTP handler based interface to communicate with the server. But let’s look at the pros and cons of Page Pipeline and Url based engines.

Page pipeline engine

The advantage of this mechanism is that you’re tied into the current ASPX page that is executing. This means any client callbacks that are made are made in the current context of the page, which in turn means form variables are POSTed back and you can access controls on the form just like in a full page POSTback.

 

This is potentially huge as it eliminates much of the need of having to pass complex parameters from the client to the server. Instead you can simply read the client state or if necessary you can even assign additional state to hidden form variables and pass that back. So to read state you can just do this.txtFirstName.Text to retrieve the current content of a control for example.

 

Both My.Ajax.Net and Script Callbacks in ASP.NET 2.0 support this (actually ASP.NET beta 2 doesn’t – for some odd reason it sends a GET and querystring values, but this is supposed to change to POST and should be fixed in the latest CTPs (can anybody confirm?))

 

The disadvantage of this approach is that this can be a big handicap for data getting passed back to the server on every hit. If you have a lot of form fields on a form – or worse have lots of viewstate – all that crap is getting sent back whether you need it or not.

 

Script Callbacks also makes handling client events way more difficult than it should be. For example, if you have multiple client callbacks you have to create multiple controls and stick them on the form and either manage the callback events in the control code or forward the events. While this isn’t difficult, it’s non-obvious and a fairly convoluted design.

 

My.Ajax.NET uses an Attribute based mechanism to map client callbacks directly back to an Attributed server side method, which is actually a much simpler approach and provides a more consistent model that works well on both the client (which gets a matching JavaScript object to call methods on).

Page pipeline callbacks will work great for semi stateful page like this example where data mostly deals with form control based data. In that example, POSTing back data to the server makes sense to some degree.

 

The other problem with page based Pipelines is that they HAVE TO post back to the same page. This is not always a good thing as it forces you to manage multiple UI contexts in a single page. The classic example for me here is the InvoiceList that does hover over popups that display the invoice detail. Do really want to generate the HTML display for individual invoice as part of the Invoice listing page? This would mean the invoice listing page actually handles 2 separate UI contexts – both the List creation and the Detail Item creation, which is not cool at all. If you have a few of those imaging the bloat that will occur in a single page.

 

URL based Engine

This is where a URL based engine comes in. There are many scenarios that I can think of where you simple want to go to another URL to retrieve the content for the AJAX request. Whether it’s HTML created by another page or output that comes from some sort of data service that feeds data to the page. Imagine for example that you have an XML based data service that forwards data requests directly to your client side page – you wouldn’t want to feed that data out of the existing ASPX page, but rather at a URL that’s responsible for managing the Data access generation. Heck, you can call Sql Server SQLXML via IIS directly to feed you the data – can’t do that with either of the tools above.


The other scenario is HTML pop overs or Html Fragment generation that gets embedded into an existing page. Again, if you do this the most likely scenario is to generate this HTML externally to a page not within it. You really don’t want to pollute your pages with multiple technically unrelated UI contexts.

 

To address this I use a custom control I created – wwHoverPanel - that is URL based. You pass it a URL and a dynamic querystring and pulls that HTML down to the client. The control can manage hover windows like the one in the example above automatically – all you do is set a few properties (URL, size of the window) and hook up the event to a callback function and the rest is taken care of. The control can both automatically display the result in a hover window, or you can route the content to a script callback handler much like Script Callbacks or the My.Ajax.NET library does. It also supports POST data (optionally – you can turn it on or off) and exposes the XmlHttp object so you can gain easy access to the responseXml property. This is underrated – ironic that most AJAX implementation DON’T actually use XML – since it makes it much easier to consume XML directly without having to resort to XML strings and manually loading browser dependent XML DOM instances. Note that the POST mechanism actually just works into the page pipeline if you post back to the same page. There’s really no magic here – simply posting back the form’s POST content is all that is needed – ASP.NET handles all the rest including assigning the control values.

 

This approach works extremely well for URL based access. It can be done with practically no code (other than the event hookups) and you can externally create the URLs that feed content.

 

The downside to a URL based approach is has no explicit server side callback support (at least not yet <g>) and well, it’s a bit simplistic. But that’s really the point – the idea is that if you want to just retrieve URL based content especially if it’s coming from a different URL it can be easily accomplished.

 

 

 

 

Which of these approaches is better? Neither – they are complimentary to each other and can be used side by side as I am doing right now. At the moment I don’t see how they can be easily combined into a single model, because the target is so different. Within the single page mode I really like the Attribute based approach that My Ajax .NET uses. If I need to pass raw data or messages this approach works better especially since it provides for some type conversion features that make it easy to pass things like DataTables/DataRows.

But on a lot of pages I simply pull plain HTML content into a page and for that the URL approach works much better.

 


The Voices of Reason


 

Carl Olson, Jr.
July 29, 2005

# re: Some Ajax for .NET Tool Thoughts

Just to add to mix, I've been playing around with www.dart.com's so-called "LiveControls". I haven't got my head fully wrapped around this stuff yet... it certainly requires a different way of thinking and architecting an application. Page-pipeline vs url! Goodness... back to the books for me.

By the way, is your custom control wwHoverPanel available? Thanks!

Rick Strahl
July 29, 2005

# re: Some Ajax for .NET Tool Thoughts

Carl,

I've been meaning to post the Hover control along with an article that describes how it works. The article is nearly done, but i've been too busy to finish it off. I'm hoping this weekend.

Peter Bromberg
July 29, 2005

# re: Some Ajax for .NET Tool Thoughts

Rick,
I agree that both approaches are necessary (the page lifecycle and the URL or "Service-based"). Having read Bertrand Leroy's blog extensively and played with his RefreshPanel and the ECMASCript Object, I am confident that the ATLAS project will address both issues.

Of course, my 2 cents is that it would be nice if everybody would just call it what it really is - Remote Scripting. Less buzzwords=less confusion. Cheers.

Rick Strahl
July 29, 2005

# re: Some Ajax for .NET Tool Thoughts

Hi Peter,

I think Microsoft is likely to get this right, although Script Callbacks was a bad start, IMHO <g>. But then Script Callbacks was in ASP.NET a long while back before anybody really put a lot of thought into 'AJAX'.

The problem with Bertrand's stuff is that it's pretty complex and not very approachable as he's working around the limitations of script callbacks. The whole interface based approach is just cumbersome and limited. Bertrand's stuff is clever and well done, but it's a hack around the original architecture.

So yes, I hope MS can get Atlas right. I hope the process they'll use to put this out will be open to discussion.


OdeToCode Links
July 31, 2005

# OdeToCode Links For July 31


Secret SQL Reporting Services Perfmon counters uncovered!

Scott C. Reynolds has a great comeback...

Robin Curry
July 31, 2005

# AJAX and ASP.NET Resources


Tom Kelly
August 03, 2005

# re: Some Ajax for .NET Tool Thoughts

Rick,
First I want to take a moment here and thank you as well as the other contributors for the Ajax reviews, it really helps those with limited knowledge gain insight to the future, which actually happened in the past, so we can apply it today.
I have chased down using both "Ajax.NET from Michael Schwarz Ajax" and "Jason Diamonds {JD-Ajax}" approach. I tend to agree that JD-Ajax is cleaner. It has also got me closer to my goal; which is to use a combination of postbacks and client callbacks. Enhancing the GridView operation is where I this is heading.

Tom Kelly
August 03, 2005

# re: Some Ajax for .NET Tool Thoughts

To continue..
My issue may be fundermental, but while working with "JD-Ajax" I soon realized "du!" that ViewState is having trouble tracking "listbox" items added via callbacks. Textboxes on the other hand work fine.
I have modified "JD-Ajax", which I need to send to him, allowing for the list box selected item to be included when you do a Ajax method client call to the server. The version I had did not provide what was selected.
In the process of chasing this down, and by adding a postback enabled button, I soon discovered that appears ViewState implicitly tracks textboxes, but as you stated on another page "watch out for list boxes".
I understand the bloat of Viewstate, but it appears that in ASP 2.0 that they have become more efficient. When paging the ViewState, under 2.0, it did not grow or should I say increase in size per page, like I saw it do in ASP 1.1 as you paged forward. This could have been a limitation of my 1.1 design, no matter. For my own limitations I need to rely on viewstate to assist me on the server for my n-tier design.

So in summary I want my cake and eat it too:)
I want my client callbacks, and all the changes I made "in the clients browser DOM" to show up when I do a postback on server. Sounds like the concept of "Atlas", if I have kept up on my readings.

With all of this stated, my goal is to sprinkle or spray, depending which cleaner type you use, just enough Ajax onto my ASP 2.0 pages to make them sparkle and shine.

Any comments are appreciated.....

Bertrand Le Roy
August 05, 2005

# re: Some Ajax for .NET Tool Thoughts

JD-Ajax seems to be really promising.
One thing that I haven't seen discussed much about page-based approaches is how to keep the viewstate consistent. While this is not a problem with postbacks that are always sequential, it is a big one for callbacks which can happen in parallel. This is the reason why callbacks send the initial state of the form and do not update the viewstate.
How does JD-Ajax solve this problem? Does he send the initial form? Does he update ViewState? What about concurrent requests?

Rick Strahl
August 05, 2005

# re: Some Ajax for .NET Tool Thoughts

Hi Bertrand,

The viewstate goes through the page pipeline - JD's stuff doesn't do anything to the post data other than collecting the form vars and sending them back. ASP.NET just works on the other end parsing the inbound data as a normal request would. I haven't looked that closely how where JD hooks the callback in exactly in the pipeline.

But, I'm not sure that viewstate would be a problem. The original viewstate shouldn't be changed by a callback. You're POSTing to the page, but there's no new page generated where Viewstate could be corrupted.

You're not POSTing back and updating the page through the local controls, but sending back a response, so setting ViewState wouldn't make any sense in this context. The client code is responsible for updating controls. So ViewState is never affected. And the ASP.NET Page rendering is essentially bypassed in the response.

Am I misunderstanding your question? I think you may be way ahead of me here in more deep thinking of integration into the Page Pipeline that you guys are doing for Atlas <g>. I've played around with multiple async calls with JD-Ajax and haven't seen any problems at this point. Doesn't mean there couldn't be though since I haven't stressed it much at this point...

Ben Hyrman
August 13, 2005

# re: Some Ajax for .NET Tool Thoughts

Rick,

Have you posted your article for the HTML pop-over? I'm very interested in reading it... there is some great stuff on your site!

Rick Strahl's Web Log
October 15, 2006

# 'My Ajax.NET' library from Jason Diamond - Rick Strahl's Web Log

I ran into Jason Diamonds My AJAX.NET library while looking for an example for my Remote Scripting session at the Portland User Group today. This short and sweet and very easy to use 'AJAX' library is tiny, self-contained and highly functional. It comes with source code and it's free and I was able to throw a quick demo application together in very little time. Check it out...

Robin Curry
January 29, 2007

# Robin Curry - AJAX and ASP.NET Resources


Robin Curry
March 01, 2007

# Robin Curry - March, 2005

# My Ajax.NET, Release 3 &lt; (a Weblog by Jason Diamond)


West Wind  © Rick Strahl, West Wind Technologies, 2005 - 2021