Tuesday, November 11th, 2008

JavaScript Object Observability in ASP.NET Ajax 4.0

Category: Atlas, Microsoft

<p>Dave Reed wrote in to tell us about an article he’s written about Microsoft ASP.NET Ajax’s utility for adding observability to JavaScript objects. The idea is simple:

The Microsoft AJAX 4.0 preview includes this Sys.Observer class that allows you to be notified of updates to POJO’s, provided you use its APIs to modify them.

Sys.Observer provides a mechanism for registering (and de-registering) listeners to be notified when values change in the object:

< view plain text >
  1. Sys.Observer.addPropertyChanged(objectToObserve, callbackFunction);

However, you must use Sys.Observer to make changes to the objects being observed:

< view plain text >
  1. Sys.Observer.setValue(objectToServe, "property", "newValue");

Alternatively, you can have the framework add a setValue() function directly to the object being observed:

< view plain text >
  1. Sys.Observer.observe(objectToObserve);

See the full article for more details.

Related Content:

Posted by Ben Galbraith at 7:00 am

2.7 rating from 32 votes


Comments feed TrackBack URI

Looks like you guys missed a synchronized in the Ajaxian Editor Engine :)

Interesting article anyway.

Comment by Malde — November 11, 2008

Typical Microsoft originality: SproutCore has this, which is simply a JS reimplementation of Cocoa bindings. (Also DataBinding in .NET).


Comment by millenomi — November 11, 2008

@millenomi: Oh, come on. As if Cocoa invented it.

I have a different problem with this: sure, it’s easy to implement watch in all browsers, as long as you impose heavy conventions on assigning and reading from object properties. And at that point they’re no longer “plan old JavaScript objects,” are they?

It’s like saying, “Our scientists have figured out how to use a blender to make Pop-Tarts! All you have to do is enhance your blender with this Toaster Expansion Unit…”

Comment by savetheclocktower — November 11, 2008

The point is the scenarios it enables, such as declarative live bindings.

Comment by BertrandLeRoy — November 11, 2008

Oh, and there is no claim for originality here as this is pretty much a canonical implementation of the very well known Observer pattern (in GoF).

Comment by BertrandLeRoy — November 11, 2008

I suggest you look at Bertrand’s demo of live bindings and templates. This feature really was necessary to enable that feature. We happened to make it public, for your benefit, and yeah, there’s certainly no claim of originality :) Its a pretty standard pattern. We implemented it.

Comment by InfinitiesLoop — November 11, 2008

Oh and I should point out as I did in my article’s comments, this is by no means a replacement for modifying objects. We arent expecting you to use it everywhere, just in case someone is listening. We expect this could be used in targetted scenarios.

Comment by InfinitiesLoop — November 11, 2008

automatically? what’s automatic about delegating all calls to a wrapper class that emits events?
also, please don’t abuse the term ‘pojo’. that term has been used to refer to ‘plain old java objects’ for years. since we have technologies that cross language boundaries (such as GWT), this will only lead to confusion.

Comment by abickford — November 11, 2008

User changes value of input field, change gets propagated to data object and other listeners without the app having to write any code, that’s “automatic” in my book.

Comment by BertrandLeRoy — November 11, 2008

to me automatic would mean exactly that, automatic: object.prop = ‘value’ and all registered listeners would be called. i shouldn’t have to call a wrapper class to make the property observable and i shouldn’t have to call that wrapper to update property values.
i guess after years of event driven arcitecture using the javabean model, this is pretty meh.

Comment by abickford — November 11, 2008

Unfortunately that is currently impossible in cross-browser JavaScript. Again, this is a well known design pattern. We implemented it. Not expecting anyone to go “wow, this is incredibly cool and new” about it. Still very, very useful and not so common in script.

Comment by BertrandLeRoy — November 11, 2008

@abickford: even javabeans require getters and setters. Would you prefer object.setProp(‘value’)?

Comment by genericallyloud — November 11, 2008

html components for IE browsers…

Comment by TNO — November 11, 2008

@genericallyloud – that’s my point, this is just the ‘bean pattern’ in javascript. i’m not bashing the pattern’s power or usefulness at all, i guess i was expecting something more like what C# does w/properties.
i wish java did event observation ‘automatically’ as well, i’m really sick of writing all the boilerplate ‘bean support’ code.

Comment by abickford — November 12, 2008

@abickford: thanks for the clarification, that makes total sense. This will likely become possible in the future thanks to native implementations of getters and setters but in the meantime we are stuck with such constructs.

Comment by BertrandLeRoy — November 12, 2008

Does anyone care about ASP.NET Ajax? Who’d use it when frameworks like Ext exist?

Comment by RichW — November 12, 2008

Getters and Setters are supported by HTML components and VBScript natively in IE for the client side as I mentioned . Getters and Setters are supported natively in Firefox since version 2 I believe. Not 100% on how far back the other browsers support it, but wouldn’t that cover 95% of your base anyway?

Comment by TNO — November 13, 2008

@Rich: you’d be surprised. To give you an idea, the Ajax Control Toolkit, which is an optional set of widgets on top of ASP.NET Ajax, is downloaded about 3500 times a day (http://www.codeplex.com/AjaxControlToolkit/stats).

@TNO: even using VBScript on IE (which would be quite hacky), you would need to add getters and setters for all properties of your objects (which would miss anything dynamically created after that) and you would still miss the case of collection changes. You would actually need a full missing member feature such as Ruby’s to reproduce this.
Implementing the observer pattern is simpler and gets the work done for the main application here, which are live bindings.

Comment by BertrandLeRoy — November 13, 2008

This is one method I was referring to:

Comment by TNO — November 13, 2008

@TNO: sure, that’s how I understood it. See how you have to declare in advance what fields you want to watch? If you set tmp.somethingelse, you won’t get notified. You would also have to explicitly write code into each getter and setter to notify listeners (we also have this pattern in our own components by the way which make it possible to listen to change events on Microsoft Ajax components without having to resort to using the observer, but this doesn’t work on plain objects). So this is an interesting experiment, and one might very well build a nice component model based on it but it is quite far from what we’ve tried to achieve here, even in intention. With the observer pattern, you can observe objects that have not been built to adhere to any specific pattern and build a context where notifications get issued and listened to in a way that the burden of enforcing the contract is not on the observee but on the observer. This is what we needed for live bindings and what made it compelling for us.

Comment by BertrandLeRoy — November 13, 2008

Leave a comment

You must be logged in to post a comment.