Well articulated, Miljan, and an excellent pre-emption against those who might be inclined to call your new moniker that most dreaded of internet words: "hype". What you describe as "true asp.net ajax ..." is clearly not hype, but rather an important distinction that will set the work that your developers have done apart from the rest of the pack.

When it comes to "True ASP.NET AJAX Controls", it seems there is missing aspect that the market still needs to address. That is, we need a way to make components aware of the Ajax nature where state information often is not needed in postbacks to the server. Currently, ViewState and other Hidden form variables are extensively used by ComponentArt (and all other vendors), even when they are an unnecessary burden on the Ajax process. I hope more progress is made in the near future to allow clients to selectively disable use of ViewState or ControlState and Hidden form variables for Ajax applications where the information in question is not needed during postbacks (both on the request and response side). This is significant baggage, especially on elaborate Ajax websites. Will CA be the first to offer this feature?

Interesting point Jonathan!

Yes - there are scenarios where the state is not needed, and the overall application performance would be improved if it was not sent over the wire on each post.

Thankfully, viewstate can already be disabled on any ASP.NET control by setting the EnableViewState property to false. All ComponentArt controls respect this setting.

Miljan ... shortly after I posted my comment, I realized that I could have more clearly stated how this class of concern is not so easily avoided. The unfortunate property of setting ViewState to false is that all child controls' ViewState property will also become false. If an application does need ViewState on certain child controls, one would be forced to enable ViewState on parent controls even if the parent's ViewState is 100% unnecessary. Perhaps the best case in point where disabling ViewState would be problematic would be with the Splitter control, which is often a high level parent control. Disabling a splitter's viewstate means that no child controls can make use of ViewState. The other concern that arises with Ajax is the growing use of ControlState which can't be explicitly disabled. While ControlState may be relavent in a normal postback environment, it may be irrelavent in an Ajax app. I point this out as a possible concern since I have no idea how much ComponentArt relies on ControlState. Any ideas how Component Art can address this ViewState/ControlState/Hidden Form vars conundrum in its components in a way that does not interfere with the ViewState of child controls?

Right - the current ASP.NET viewstate model essentially requires setting EnableViewState on leaf controls in the tree. If you set it on a parent control - all of its child controls will inherit that setting, and won't be able to override it, as you noticed.

We find that this isn't a huge problem in most real life situations because controls that can contain other child controls typically don't save a lot of viewstate data. For example, if you have a Splitter control with nested TreeView and Grid controls - the actual size if Splitter's viewstate is negligible when compared to that of TreeView or Grid. Therefore, you don't lose much performance-wise, if you keep Splitter's viewstate, and enable/disable it on its child controls. Same goes for MultiPage, Snap and other container-type of controls.

Your general point is valid, though. We have done quite a bit of work to optimize what's being posted back to the server by our controls. We don't use the built-in ASP.NET viewstate nor control state at all. We have a custom viewstate mechanism which is much more efficient. Explaining the details of our viewstate implementation would perhaps make for an interesting blog post in its own right...

I'm a bit confused by this distinction of being "True ASP.NET Ajax" components. While I'm impressed with the initial steps that you've made with the client-side API, it seems as though you still have fairly limited ability to *fully* manipulate the underlying client-side data models. Ultimately, it would seem as though I should be able to leverage ASP.NET Ajax to make web service call to retrieve the JavaScript objects that are part of my data model, then tell the ComponentArt components to re-bind to this data. Getting just the data *without re-rendering any of the component" would be maximizing the value of Ajax (at least from my perspective). However, I'm under the impression the current implementation does not support this model. Essentially, if I need to re-populate a grid, for example, I cannot just re-fetch its data via ASP.NET Ajax and re-bind it to the grid (even manually). Is the an accurate assessment of what the controls can achieve now or have I overlooked some client-side data binding features? If it's not possible, how could I best achieve the dynamic I'm after now without continually re-rendering controls when all that's changing is their data?

Todd, just to clarify: ComponentArt Web.UI for ASP.NET AJAX controls are "true ASP.NET AJAX components" simply because they follow the new ASP.NET AJAX client-side component model. This component model consists of:

1. Standards for defining client-side classes that expose properties, methods, and events; and

2. Client-side base classes for component and controls: Sys.Component and Sys.UI.Control.

As for your question, I agree - it would be great if the controls supported automatic client-side binding with web services. This is definitely something we are considering for the next version.

It should be noted that this is possible even with the current version - it just requires using the client-side API to build the structure of a control (say Grid or TreeView) based on the results returned by the web service. This would produce the same user experience as automatic client-side binding with web services, but it requires some (perhaps unnecessary) JavaScript coding. It would be great if the controls just "knew" how to bind with web services.

If you need help to get this functionality going with the current version, please let me know.

seems interesting, but if you're going to do client side scripting wouldn't it be better to use javascript libraries like jquery, yahoo UI or ext js? the MS ajax library isn't that good. give me commerical asp.net controls using yahoo ui and i'll bite. the model you describe is basically what we do at our shop with ext js.