in Uncategorized

May ASP.NET AJAX Futures CTP… wtf?

Soooo, ok, they released a new May CTP of ASP.NET AJAX futures. It’s got some new support in there for Silverlight related stuff now. Great, awesome, love to see it and totally understand they need to pimp the new platform. What has really happened beyond that though? I’m not seeing (m)any differences in the xml-script, bindings, controls and animation code that (used to?) make(s) up the real power of the previous release of the futures.

As a simple example, let’s start with the fact that there’s no standard ICollection interface. There’s INotifyCollectionChanged (weird considering there’s no ICollection, eh?) and there’s loose support for duck typing of a collection class within some of the controls, but no true ICollection yet.

As a more complex example at the Selector control. First off it’s data-binding support is weaker than that of ListView. Selector can either take a “pure” JavaScript array of objects, which it wraps with a DataTable (heavy handed), or it can take an instance of an object which is parses using parseFromJson (bad name if you ask me… JSON is the serialization format, not the runtime representation of the object) and, again, turns it into a DataTable. ListView on the other hand supports that concept of a custom collection (through duck typing as I mentioned above). Selector also doesn’t even expose a way to get at the currently selected item. Sure it gives you the selected index, but that’s extremely useless in binding scenarios which is the most powerful feature of the futures. We actually extended the prototype of Selector here at Mimeo to support  the above shortcomings in anticipation of it being added in the next drop. If anyone else wants these enhancements, click here to download.

Even further still, DataSource doesn’t properly support custom WebServices (i.e. Sys.Preview.Data.ServiceType.Handler). Neither does ServiceMethodRequest. which always wraps the parameters as DataService parameters (i.e. parameters + loadMethod), so we can’t even call our own web methods using it without creating a shim method on the web service likse MySearchHACK(Dictionary<string, string>, string) and then converts the parameters and calls the real method which is MySearch(string, int).

Anyway, it seems like Silverlight is ursurping the development of the core AJAX futures and, while I’m all for Silverlight, I think it’s a bad move to put these features on the backburner. They should be fleshed out and delivered. They are extremely valuable to those of us trying to build rich web browser (only) based applications.

I’d love to hear from someone inside MS on what exactly their intentions are at this point. If it’s dead, fine… just let us know. If it’s not, tell us what to expect and when to expect it so we can make decisions on how to proceed. I’ve said it before and I’ll say it again, the stuff that was cut from ASP.NET AJAX 1.0 and ended up in the futures was much more important to developing rich internet applications than 1.0. It’s true that 1.0 layed the groundwork, but having to cobble together all the UI in JavaScript still with $get and $addHandler, while possible, isn’t what I’d call a good platform. I want to do:

<page xmlns=”….”>
  <serviceRequest id=”myWebServiceRequest” url=”MySearch.asmx” methodName=”Search” useGet=”false” />
  <textBox id=”mySearchText”/>
  <button id=”myButton”>
      <invokeMethodAction target=”myWebServiceRequest” method=”invoke”>
            <binding dataSource=”mySearchText” dataPath=”text” property=”parameters” propertyKey=”searchText” />

Declarative, simple, no code. That was the power of ASP.NET AJAX before the split and hopefully remains the power when (if?) the futures are ever truly delivered.

Leave a comment


  1. Here here!Although I gotta say, I’m increasingly wondering if XML is the way to go for declaratively wiring up components. Why not use a JSON structure?

  2. Kevin: JSON is something that has been considered but we chose XML because the tooling already exists and because the syntax would have been more obscure (for example, in XML the tag/type mapping is obvious, but not so much in JSON).Also to answer one of the questions of the post, what’s in the Futures in in no way “dead”, it’s stuff we still need feedback on to determine what the right design is and what should or shouldn’t be in the fully-supported product. So thanks for the post, it’s all very valuable feedback. Forwarding to the rest of the team.

  3. Betrand,Great to hear from someone on this… especially you. ;)I’d love to have an open channel to you guys because we’re putting this stuff to use and finding/fixing bugs. I just don’t know where to go with the feedback at this point.I tried to get in touch with Steve Marx and Richard Ersek last month to see if there was any kind of program I could get on (like Atlas SSR) to provide feedback on these items, but never heard back from them.Cheers,Drew

  4. Sure, feel free to drop me e-mail (bleroy you know where). That should work just fine. Who needs those programs 😉 ?

  5. No code? Do you think this is not code:<click><invokeMethodAction target=”myWebServiceRequest” method=”invoke”>I have a brand new invention, CVS code:event, action, target, methodclick, invokeMethodAction, myWebServiceRequest, invokeColl huh, no code at all!

  6. Well, of course it’s code, but it’s much cleaner/simpler than the superfluous amounts of JavaScript you would have to write to achieve the same thing. :P-Drew

  7. I downloaded the Futures CTP, but I can not find ANY examples on the web, etc on how to use the controls. Any help would be much appreciated. Thanks!