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

ATLAS for ASP.NET grows up


:P
On this page:

A few weeks ago Microsoft announced new naming for the product formerly known as Prince – eh, ATLAS.  The names Microsoft came up with are the ultra-catchy Microsoft AJAX Library for the client side JavaScript framework and Microsoft ASP.NET 2.0 AJAX Extensions. Rolls right off the tongue, doesn’t it? All kidding about the boring names aside the new names are  descriptive of the functionality and they include AJAX in the name so it’s quite clear what their purpose is. I suspect it will take a while to lose the ATLAS moniker though and I’ll use it here to keep it short.

The Roadmap

Once codenames like ATLAS come off, it’s usually a sign that the technology is heading down the road to the marketing department which in turn means that it’s getting at least somewhat close to a release cycle and feature lockdown. Scott Guthrie announced the roadmap (http://weblogs.asp.net/scottgu/) for ATLAS which calls for a 1.0 release sometime at the end of the year with a public beta and release candidate between now and that time.

This initial release is set to be a ‘core’ product that provides the base AJAX client and server functionality. According to Microsoft this will include most but not all of the features that are currently supported by the ATLAS CTPs. The rest of the controls are still going to be provided but they may not be part of the core supported set for the 1.0 release and will continue to be improved upon with further CTPs.

It’s a bit confusing, but the goal is to push out a full release of ATLAS soon so that developers can include “official and supported” Microsoft AJAX technology in their applications without running pre-release software. I know this has been a concern for me personally as I’ve not been able to integrate ATLAS into my own tools due to issues with unsupported software for our customers. So to date I continue to use and update my own AJAX library while spending my time getting up to speed with ATLAS.

The 1.0 release is a framework release only and doesn’t include any tool support, so don’t expect better JavaScript or special designer support for creating client side code or controls.  Tool support is scheduled for the next release of Visual Studio code named Orcas which is rumored to go into early previews around the time ATLAS 1.0 ships. Orcas focuses on the next generation of tools from Microsoft including Vista and .NET Framework 3.0 support tools as well as tools for the ASP.NET AJAX tools. The final release of this next version of Visual Studio however is a long ways off – Microsoft has hinted at projected release at the end of next year, but I wouldn’t hold my breath given the scheduling delays Microsoft developer tools have been going through for the last few major release cycles. In short, for the moment don’t consider getting improved tool support for your Microsoft AJAX applications any time soon.

Where are we at?

Atlas has come a long way since the first presentations that Shanku Niyogi and Nikhil Kothari gave at PDC about a year ago now. I remember sitting in both those session being both excited and massively overwhelmed. I also remember looking around the room at a bunch of shell-shocked faces who appeared to feel similar. There was excitement, but also a lot of trepidation of the complexity and sheer size and functionality of what this AJAX framework promised. Microsoft doesn’t do anything small, and the ATLAS framework is a monument to that very approach. It provides a variety of different mechanisms by which to create rich browser applications. You get a server centric approach that abstracts you from JavaScript and client side code altogether, or you can use the Web Service Bridge to provide a more pedal to the metal approach using raw JavaScript. And if you’re really adventurous (at this point) you can use the client side JavaScript library, which is very powerful but complex and woefully undocumented at the moment (the source is the documentation).

In a way ATLAS and the inner workings of ATLAS have a level of complexity that rivals the ASP.NET engine itself. Luckily, just like ASP.NET it’s not necessary to understand all the details of how it works to use the technology effectively, but if you are one of the geeky types like me who likes to understand how the technology works and how each of the mechanisms impacts your application’s performance and design, you’ll have some spelunking to do beyond the 5 minute walkthroughs from the ATLAS Web site. The same is true if you plan to build controls that are ATLAS enabled. Currently there’s no clear path to building ATLAS enabled controls that have both client and server components. Make no bones about it ATLAS is a complex framework and there a lot of issues that you need to consider to build effective applications even if some of the features like UpdatePanel appear to be super simple and almost too good to be true.

A lot has changed from that original framework since the original showing at PDC. To some extent ATLAS was changed by community input. Immediately following PDC Microsoft released a very rough preview as a work in progress and looked to the community input on various forums to see how people applied the technology, what worked and what didn’t. Some features were pulled, others downplayed a bit (XmlScript for example) and some improved considerably (UpdatePanel) due to popular demand. Microsoft has been very responsive to community input, and some of the changes that have occurred to the framework appear to be customer driven which is very encouraging.

As I’m writing this we’re at the Community Technical Preview (CTP) stage, which means ATLAS is still a pre-release, pre-beta product. However, the last few releases have been fairly stable both in terms of code stability as well as feature creep. It’s been nearly two months since the last CTP (July) so it looks like a lot of work is being done at Microsoft to ramp up for a milestone release. According to Microsoft sources a beta release is not far off.

Even so I think an end of year release is pretty optimistic, given that there are a still a number of open issues, especially in the server controls that haven’t been adequately addressed and with 3 months to the end of the year it seems that time’s getting short. I’d prefer a solid first release over meeting an artificial end of year deadline.

Taking Atlas on the Road

Over the last couple of months I’ve given a number of ATLAS presentations at user groups and Code Camps and I’ve had a chance to talk to a fair number of developers and hear and see their expectations and reactions to the ATLAS technology. ATLAS has come a long way since PDC and it’s become a lot easier to use, so it’s much easier to present ATLAS as technology that can be used today in your applications.

I still am convinced that most Web applications can do just fine without AJAX technology and if they do use it, they can and should use it judiciously to provide additional functionality to the application. But in the right situations AJAX can provide definite practical advantages and that’s what I’ve been focusing on. I always ask the question of how people intend to use AJAX functionality in their applications and not surprisingly very few have a good idea how they want to apply the technology. AJAX doesn’t fit everywhere and I think it’s certainly not a new paradigm as some people paint the technology.

It’s interesting to see how the expectations of what AJAX is and how it should work seems to polarize into two clear camps: Those that want a very lightweight mechanism to call server functionality, and those that just want an easy mechanism to do AJAX.

ATLAS actually addresses both of these scenarios rather well, but I’ve been surprised that there’s a lot of resistance to ATLAS – sometimes bitterly as if ATLAS were raining on somebody’s parade. This resistance tends to come from early adopters who are already using other AJAX libraries, which are in many ways easier to use and much more light weight than ATLAS. There are many other choices out there like Anthem.NET (anthem-dot-net.sourceforge.net) which I happen to like a lot, Ajax.NET (www.ajaxpro.info) as well as non ASP.NET specific solutions like Prototype (prototype.conio.net) or Dojo (/dojotoolkit.org). I’ve been also been using a home grown library (www.west-wind.com/tools/wwHoverPanel) for some redistributable tools. Third party vendors have also started to crank out proprietary AJAX implementations some of which are very powerful and easy to use. These tools work well and for the most part are very lightweight and easy to use. Compared to them ATLAS at first blush feels like an elephant in a porcelain store.

So, for existing AJAX developers, why bother with ATLAS? My first suggestion is if you have something that works well for you, and you are comfortable with the tool, you should consider sticking with your existing solution. There might be technical reasons to move to ATLAS, but more likely the reasons are going to be political. There are good reasons to use a tool that comes ‘in the box’ or at least from Microsoft. If you’re a vendor or tool provider you certainly want to minimize your external tool footprint. I know I find myself in this spot quite a bit as I have some tools that I sell where I want to avoid third party tools, so my choices are either to build my own (as I’ve done) or use what comes in the Microsoft box. Unfortunately in the case of AJAX the Microsoft currently is still in pre-release so for the moment I’m using my homegrown solution. The advantage with a homegrown solution is that I can tweak and adjust it and keep it light weight. And because I control it I’ve been building it to try and match some of ATLAS’ functionality to make moving the code in the future easier.

Framework Size

So, one of the most frequent concerns I’ve heard is the size of the ATLAS framework and the overhead that it is pushing over the wire. This is a valid concern for AJAX applications, but I think that ATLAS actually makes reasonable demands on the network for the functionality it provides.

The first complaint usually comes from the size of the massive client library which uncompressed is nearly 400k in size. With GZIP Web Resource compression which is provided as part of ATLAS  the base library hit compresses down to about 56k which is still pretty large – like the size of a large image. But remember that JavaScript libraries are cached so this is a onetime hit for a typical user on a site and given the feature set of that library I’d say a very worthwhile hit. Microsoft is also still working on optimizing the compression of the library so it may get smaller and more modular yet.

The next size issue is more important and is related to the use of UpdatePanel and the server controls in general. The ATLAS  server controls are based on the ASP.NET page pipeline so they sent up full POST data including ViewState and EventValidation and the server returns HTML fragments for any updateable regions of the page, plus ViewState and any script code the page or its controls generate. The size of the result varies depending on the size of the updated area of the page, but even if you were to retrieve a small portion of a large page chances are you’d be passing a significant chunk of the original page size over the wire. (example: www.west-wind.com/atlas/CustomerList/CustomerListUpdatePanel.aspx)

UpdatePanels are basically mini-page postbacks and you should treat them as such. If you’re building a frequently updating page that maybe has a timer on it and updates portions every few seconds on a heavily loaded site that may not be the best of ideas. But if you are dealing with more traditional page updates by clicking on link always keep in mind that while ATLAS UpdatePanel post backs may be large for typical AJAX solutions, remember that a full page postback without any AJAX would be larger yet and we’ve made do with that for years. In other words you’re still reducing the amount of traffic compared to a full post back.

But ATLAS also provides more low level and more efficient alternatives for making callbacks that send only the data you specify. You can for example, use client script code directly and use the server as merely a data service and pushing only a small of data back and forth between the client and server. The easiest way to do this is to use the Web Services bridge from client code which allows you with a few lines of script code to call server side ASMX Web service methods that return only the actual result data. ATLAS manages these Web Services calls for you by converting parameters and result values to and from JSON (JavaScript Object Notation) encoding and by providing proxy classes that make the remote service calls as easy as a single function call with a callback handler you specify.

But when the data returns at that point it becomes your responsibility to apply it to the page with JavaScript or the ATLAS client library, whereas with update panel the updating is handled automatically by the ATLAS framework.  But for high traffic scenarios low level access is definitely preferable (example: http://www.west-wind.com/atlas/Chat/Chat.aspx)

Which Approach is right?

I get a lot of questions in regards to which approach to use with ATLAS. Should we use UpdatePanels, or should we use low level functionality? How do you know which to chose? There’s no clear answer to this question and you have to weigh the benefits of each of the approaches. UpdatePanels are easy to use, but there’s significantly more overhead. Low Level access is more efficient but requires manually written client side code. Your application environment obviously has an impact too – are your users going to be using high speed connections or are there going to be many connecting with modems? Obviously this will affect your choice of tool.

But also consider that you don’t have to stick to one approach. You can mix and match various ATLAS features even on the same page. For example, you may have a page that requires rapid fire update requests to the server to provide some progress information, but to draw the final result as a data grid you might prefer to use an UpdatePanel to display the result using server logic rather than rendering the result on the client. (example: www.west-wind.com/atlas/LongProgress/LongProgress.aspx and www.west-wind.com/atlas/StockService/StockDisplay.aspx)

Mix and match functionality can provide the best of both worlds. Many folks want to avoid JavaScript altogether, but I think it’s vital to examine the application at hand and decide what works best. While writing JavaScript with the current crop of development tools is painful, many operations can be handled relatively easily. And once the client side ATLAS library gets some decent documentation, it can reduce some of the most painful aspects of dealing with browser incompatibilities. Unfortunately in its current state the client library is a bear to use as usable documentation and discoverability of the functionality is nearly non-existent.

If you’re going down the AJAX path, JavaScript is going to become a more important part of your development environment. This will get easier when Orcas arrives, but in the meantime we have to struggle with the existing tools. Investing some time getting acquainted with JavaScript should probably be high on your list of skills to acquire as a Web developer. Learning about JavaScript object orientation, prototypes, function pointers, closures (an excellent reference can be found here: jibbering.com/faq/faq_notes/closures.html) and a handful of other concepts specific to JavaScript is a prerequisite to use the ATLAS client library which uses some advanced concepts to provide abstraction and .NET like functionality.

We’re not quite there yet

Overall I think that ATLAS is hitting a pretty good balance between power and complexity, between size and flexibility. But even so there are a few things that I think that are problematic and hopefully some of these will be addressed before the 1.0 release hits.

UpdatePanels in particular have a few problems, mainly in that they can’t be easily controlled through client code. You can’t easily trigger an update panel from the client without creating phony event triggers (like adding a button an calling it’s click method to fire an update). You also can’t easily trap an UpdatePanel completion event so you can’t easily hook client code to the panel. While the focus on this control is for server side operation, being able to hook up client functionality comes in handy in many situations especially if you trigger the update panel through explicit code from the client and doing things like disabling and then re-enabling controls after a callback. This is not easily done today.

Another problem is the inability to keep an update panel from updating if an event is fired from within the panel itself. UpdatePanels have two supported update modes Always and Conditional, but even Conditional will update if you fire an event inside of the panel. This can be real problematic for some controls like listboxes or dropdowns that act as event triggers, but also need to be updated. Any click on the list will always force the panel to update, which is not the desired effect. But you may want to update the list after a change has been made to the data locally or after  timed refresh to get the latest data. There are no easy workarounds for this particular scenario.

Both of these are issues have been frequently requested on the ATLAS forums. If you take a look around the ATLAS forums (forums.asp.net/default.aspx?GroupID=34) you’ll find that there are quite a few quirks with UpdatePanels. Another one I’ve run into is that list controls will not fire the ItemCommand events in Conditional update mode. They only work in Always update mode. I’m not surprised at some incompatibilities to be honest – UpdatePanel is one heck of a complex control that has to handle any standard ASP.NET scenario based on pages and controls that never ever thought about the possibility of partial updates. So, realize that there are going to be some scenarios that just don’t work with UpdatePanel. Unfortunately it’s not even easy to pin down exactly what isn’t going to work or work slightly differently than it would in a post back. The most common things you have to watch out for are any dynamically injected scripts, headers, resources and attributes. Having initially hidden controls on a page and then making them visible in an update can also cause problems if the control needs to inject script or startup code.

There are lots of little issues that currently at least can break the perfect abstraction of “just slap an UpdatePanel around that control”.  The control is impressive and works in the most common scenarios, but be aware that there might be things that don’t.

I’ve also been thinking quite a bit about using ATLAS in custom control development but I’ve found that there’s currently no clear architecture to build ATLAS enabled controls. There’s the ATLAS Controld Toolkit – eh, Microsoft Ajax Control Toolkit, which provides a wizard and base framework, but it requires yet another external assembly. Natively the ATLAS library doesn’t provide a clear control design architecture and this seems to be a big missing piece at the moment. I foresee that ATLAS controls will be a combination of client control and server control and the two communicating with each other.

The most significant shortcoming is the lack of a standardized callback mechanism that allows you to make a callback to a user or custom server control. So if you build a custom control that needs to communicate with client JavaScript code for the client side portion of the control there’s no standard mechanism for doing that. While it’s easy enough to use the client library’s WebRequest object, there’s no standard protocol on the server to route the callback to a control and pick up the data from the client or even send it back in a standard way. I’ve actually used my home grown AJAX library (www.west-wind.com/tools/wwhoverpanel) to provide for this functionality in an ATALS application as it’s much easier than the native alternatives, but support for this should be baked into ATLAS natively.

We’re moving forward

Don’t let these quirks and issues discourage you though. Overall ATLAS feels very solid and we have to remember that it is still early in the release cycle. We’re not even in Beta yet and Microsoft has acknowledged a number of the shortcomings I’ve mentioned above and is considering to address them at some point. So things will only improve from here on out.

But AJAX technology is complex behind the scenes any way you look at it. AJAX and JavaScript is volatile – much more fragile than pure server script because there are so many things that can go wrong from lack of client support, to disabled JavaScript to network errors and browser incompatible code. It’s no surprise that we’re seeing so many Web pages these days (AJAX, ATLAS or just plain rich JavaScript client pages) that are popping up browser errors even on major sites. The browser is a tough platform to debug especially for code (as if HTML/CSS wasn’t hard enough <g>).

But AJAX technology is here to stay whether we like it or not, and it’s already having an impact on expectations for web site development. At the very least Microsoft has made building these types of applications with ATLAS relatively painless, and I think that the path they’ve taken is a good one in terms of providing the functionality that developers look for with a variety of different approaches that can be mixed to provide just the right kind of behavior.


The Voices of Reason


 

Atlas and more
September 23, 2006

# Rick Strahl on ASP.NET AJAX

Rick has a very extensive post on his blog about the state of Atlas today. It&#39;s a fair and complete

scottgu
September 24, 2006

# re: ATLAS for ASP.NET grows up

One thing worth mentioning is that the final release of Atlas will have a smaller Javascript library download for the core (we've found several tricks to make it smaller). I believe is is now about 9k in total download size when running in retail mode.

When running in debug mode, it also has a lot of additional instrumentation added that helps developers validate Javascript usage better and pinpoint potential runtime errors.

Hope this helps,

Scott

Jon P.
September 24, 2006

# re: ATLAS for ASP.NET grows up

Software, as usual, seems to be in a perpetual state of beta these days, with multi-year development cycles.

I find it pointless to try and "keep up" while doing ongoing work for customers because Betas can go through substantial changes.

Atlas is a typical example in which it is now being redesigned/renamed/retooled to another product(s).

Combinations of new technologies only compounds this problem of trying to keep up, e.g. the new line of expression products.

Most releases don't become fully stsble until the sp1, so the question becomes, why try to keep up with betas ? Learning time is expensive and it is best to spend it on working, usable technologies.




Rick Strahl
September 24, 2006

# re: ATLAS for ASP.NET grows up

Scott, 9k? I heard that before but wasn't sure... Does that include the whole client library or just a baseline? Either way, down to 9k sounds awesome!

Rick Strahl
September 24, 2006

# re: ATLAS for ASP.NET grows up

Jon, I agree. I wrote on perpetual beta some time ago. http://west-wind.com/weblog/posts/1162.aspx.

The main problem I see is not so much that there is beta out there, but the fact that beta is in many cases treated like release product with all the excuses that entails for the vendor. ATLAS is a good example - it's in a state of 'go-live' license which is effectively a semi-legitimitization of the technology.

Ultimately as a normal day to day developer though, the choice is up to you whether you do the early adopter thing or not. You can wait until it releases and take advantage of the pool of knowledge and pain that has accumulated and you get a stable product.

But there are also advantages to this pre-beta stage and I think that with ATLAS this may be one of the first times where it really applies: It can help shape the product and functionality. In the past Microsoft has paid lip service to community input, but for the most part that input was taken and not fully applied. I think with a lot of things that have been coming out of Microsoft in the year since Visual Studio released has been a lot more customer centric and has been changed and driven by customer feedback (and not just feedback from insiders either). In that respect I think it's a good thing as it ultimately results in a more usable product and something that is fairly battle tested by the time it hits release.

As developer though - you have to make a concious choice to put up with incomplete bits and bad, bad documentation which I think is the biggest problem of beta products. I personally would do much better and feel more comfortable using ATLAS if the documentation was better especially for the client library.




Leo
September 24, 2006

# re: ATLAS for ASP.NET grows up

One of the weakest points in Atlas for me is the lack of a server side "control model". If you want to work using a server side architecture, you'll need UpdatePanel. The problem is that performance is not very good with UpdatePanel, because you get LOTS of data being transfered over the wire.

In Anthem.NET for example, you can work using a server side approach and still have good performance. Take the Anthem Button and Label controls... You can do like this (server side):

private void button_Click(object sender, EventArgs e)
{
label.Text = DateTime.Now.ToString();
label.UpdateAfterCallBack = true;
}

And have only this small piece transfered over the network:

Request:

&Anthem_UpdatePage=true&__VIEWSTATE=%2FwEPDwUKLTE5MDE4Mzc5MGRkCQtXiAenG6XmcD0%2FqoSvIYM%2BaMc%3D&__EVENTVALIDATION=%2FwEWAgKKwvW%2FCQLz9r7ABJ7Sehwm7yRnD6ZiMoB8VlpFeYk3&__EVENTTARGET=button&__EVENTARGUMENT=

Response:

{"value":null,"error":null,"viewState":"/wEPDwUKLTE5MDE4Mzc5MA9kFgICAQ9kFgICAw8PFgIeBFRleHQFEzI0LzA5LzIwMDYgMjE6NTA6MzVkZGRkcOpj+dapmyZzp9DEWKVlDYRb+g==","eventValidation":"/wEWAgLGn6O7BgLz9r7ABIoYDtMUJJKzkRl/ymtQj2yT/aN9","controls":{"label":"<span id=\"label\">24/09/2006 21:50:35</span>"}}

In Atlas we can't do that... To have the same effect we need to manually code javascript client-side. This is a pain! It's too bad that we don't have server side controls with this kind of functionality built in.

Dave
September 24, 2006

# Walk down memory lane

I remember back in 1999 when we were showing our Web UI to potential customers trying to explain that unlike our competitors we didn't have to post the whole page and what great usability features this was for the end users. Seeing that a lot of people were on dial-up this was a real time-saver for the end users.
Some of them "got it" other ones, well - you know...

I also remember how disappointed I was when I saw ASP.NET circa 2001. Full-Page posts, ugh - out of the box ASP.NET will be a huge leap backwords for our GUI I thought.

So here we are in 2006 and MS is releasing a framework to do this.
Is a one size fits all AJAX library worthwhile?

Time will certainly tell.

Peter Bromberg
September 24, 2006

# re: ATLAS for ASP.NET grows up

Rick,
No question that Atlas is getting ready to hold up the Remote Scripting world for .NET developers. I for one, have decided to wait until an RC or Release 1.0 to start implementing ATLAS-based solutions. One reason is that I've been having such an easy time with Anthem.Net. I like the way they've decided to provide an Anthem.Extensions namespace so developers can create new controls while keeping the base Anthem.Net library lean and uncluttered. In fact, I recently revised the AutoSuggestTextBox once again to allow for a database call with each typed letter, and use OleDb to make it more portable among data sources. It was extremely easy to do.

So your point about developers who are comfortable with their current Remote Scripting technologies certainly rings true.

Rick Strahl
September 24, 2006

# re: ATLAS for ASP.NET grows up

Leo, I agree about the control model with ATLAS. At the moment there's no real control model which is disappointing as I mentioned. Compared to the full ASP.NET framework with it's rich built-in support for control development as a core set of features ATLAS feels really lacking in this space. But I'd say give it some time - the big brunt of this sort of stuff is likely to come in the second wave when tool support is also there. (OTOH, why wait when other tools already do this right <s>)...

Dave, yes AJAX isn't new, but it's not Microsoft's fault. Microsoft was pushing this technology way back when it was released in 1998 but it got nowhere because the standards crazed folks didn't want to have anything to do with this. It took other browsers to bring a standard HTTP client to make this really a viable option (even though there other hacks with frames to make it work before in browsers other than IE).

Peter, as I mentioned ATLAS feels in many ways like behemoth that's trying to do too much. It has many, many features and the end result is that it has to a lot of things for a lot of different scenarios and the end result is a tool that's big and heavy on the wire to ensure that everything get's updated properly. I also like ANTHEM.NET alot and I've used in a couple of apps with great success. The beauty of it is it's so damn easy to use. The downside is that it's not as flexible to extend existing controls - you have to write code to do that whereas in ATLAS everything is an extender that works with any (ok most) controls. In the long run that's a better model especially for those that subclass everything or use third party controls.

Ajaxian
September 25, 2006

# Ajaxian &raquo; Ajaxian.com 2006 Survey Results

# DotNetSlackers: ATLAS for ASP.NET grows up


foobar
September 25, 2006

# re: ATLAS for ASP.NET grows up

Great post. Your blog posts have been really, really good lately Rick. Thanks for contributions to the community!

Pieter Siegers
September 26, 2006

# re: ATLAS for ASP.NET grows up

Hi all and then some more,

I am following the evolvment of Atlas and really really like the library, and use it together with Anthem.NET. I use both even together in single projects with success. I like Anthem.NET because it is simple to use and gives full control over more complex client-side process handling, while Atlas is great for ajaxifying existing web pages. I have published some articles on ASPToday.com on projects where I'm using both.

I like that way Atlas is integrated into VS.NET 2005. It's easy to start new web apps. An aspect that I find that should be mentioned here is the way Atlas can be implemented in existing projects. It's not all that easy. Especially web.config is difficult to do because of its many settings; while Anthem.NET's web.config requires none (for .NET 2.0; for 1.1 one setting is required).

Then there's overhead. I hope that Atlas is able to cut down the overhead especially the javascript; I read that Scott Guthrie claims 9k - that would be under the amount that JackBE is claiming (10k) - and I think that would be just excelent. Anthem.NET is lightweight but it can still be improved over time. JackBE is a good example of how criptic a library can be, and thus minimizes network load.

As an aside, as you may know I now participate actively in the development of the anthem extensions area, where right now I'm adding a third control, ProgressBar that allows for displaying real-time server process progress, as opposed to the updating controls that only show if the browser is updating page areas. We're planning to add a few controls more in the next coming weeks, among them an extended GridView, an extended Timer, a PopupPanel, and a TabStrip control.

NB: A wile ago i was asked to test cross-browser and found out that atlas:UpdatePanel did postbacks in Safari on Mac instead of doing callbacks. I just got a message from Scott Guthrie that "Safari support is going to be added in the October refresh". Good to finally hear that the bug is going to be disappear. For this, Anthem.NET works in all three main browsers I tested: IE on PC, FF on PC and Mac, and Safari on Mac.

All the initial work on Anthem.NET can only be credited to its creator Jason Diamond, and further excelent developer work by Andy Miller.

I look forward to being able to use the RTM of Atlas in my web applications, and hope to be able to use it with DNN 4.3.5 too. But as you say there's still a lot of work to do for both libraries!

"Atlas" UI
September 27, 2006

# ASP.NET Forums - Problems with Repeater ItemCommand Event and UpdatePanel Triggers


Temesgen
October 06, 2006

# re: ATLAS for ASP.NET grows up

This is really a good article. We are trying to ajaxify an existing big car rental website and we were using ATLAS.
I want to emphasize on the ATLAS:UpdatePanel problems when used in a context that they shouldn't be used. We were trying to update a rate panel which holds a repeater everytime some equipment is selected (checkbox.checked) wrapping the repeater with updatepanels. But reallly it takes more than a reasonable time for ATLAS to update the contents in the updatepanel. I am afarid the user would have gone to the next page without even noting that the rate was updated for the equipment selection.

Sandor from Hungary
November 17, 2006

# re: ATLAS for ASP.NET grows up

Hey Rick! Congratulations on this article, and on the whole site at all! I'm prepareing to get acquainted with this Microsoft ALAX.net thing. Thence you wrote this article, some month have been passed away, and so Microsoft released beta version of it's AJAX .net framework. How do you think if it has solved above-mentioned problems? Thx and have a nice day!

ASP.NET Forums
May 17, 2007

# Problems with Repeater ItemCommand Event and UpdatePanel Triggers - ASP.NET Forums


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