I might be missing something, but what does this give you that "dojoAttachPoint" doesn't?

Using dojoAttachPoint you can do the same w1.foo = "blah" can't you?

This technique provides an automatic wiring mechanism that listens to the changes and updates fields based on any property. Using dojoAttachPoint alone would require you to write setters/getters for each property you want to listen to. Plus, here we keep the data always synchronized in a standard JS-property and in the corresponding DOM-node.

Additionally, with this technique we can transfer some standard functions from widget-js to template declarations. With dojoAttachPoint you get access to a DOM-node on the JS-side, while with this technique it's vice-versa.

The idea originally stems from the difficulty of changing widget UI text elements on the fly. If you've set them using ${...} substitution you cannot access or reset them after rendering the widget easily without re-creating the UI. While on the other hand, with this technique you could just change the property value and that's all.

Ahhh, gotcha, for some reason I thought you could already do...

dijit.byId('dijit_TitlePane_0').titleNode = "something different";

But as you point out, you'd have to have something like:

dijit.byId('dijit_TitlePane_0').setTitleNode = "something different";

And then code a function in your widget that sets the title node value.

That being the case, this seems like a great new idea. :-)

http://thread.gmane.org/gmane.comp.web.dojo.devel/8368

That was one interesting conversation! I'm not going to summarize it all, but I'll emphasize some relevant bits.

First, the Observable-class discussed in that Observable/getter/setter thread is a solution to the IE set*-problem. So, it would be possible to update this widget type to take advantage of that for IE. (Plus, it's some pretty creative coding with VBScript as well. We've had to resort to that when working with browser plugins, but the way it's done here... nice! :))

Second, the need for something what I've done here is obviously recognized:

Fundamentally, being able to say something like:
myWidget.f.label = "some text";
and have it instantly set the innerHTML of the widget's labelNode
property would be a HUGE win for widget authors.

http://article.gmane.org/gmane.comp.web.dojo.devel/8385

Third, about the performance cost of the solution:

Of course, in some applications, property access to an object may be
infrequent, or overshadowed by other expenses (like DOM access), and the
"quality" of the interface may be more important. Bottom line, before you
build a tower, you better the count the cost, and the cost of using
getters/setters to "observe" is about 0.028ms in IE...

http://article.gmane.org/gmane.comp.web.dojo.devel/8388

Fourth, different opinions about handling performance issues:

performance implication [...] can be handled by some big fat warning.

and

I am concerned about killing perf in the name of trying to get real getters and setters, particularly in something like Dijit.

and

Therefore I mean to really have it in a separate package which clearly states the "experimental" state of it.

and

I see no reason not to use this capability to improve our APIs.

http://article.gmane.org/gmane.comp.web.dojo.devel/8391

Fifth, there are some additional limitations:

So briefly, the observable/JSdata module can take existing data stores and
make properties accessible with JavaScript for the majority case, existing
primitive values. However, it is slow and has a somewhat more complicated
set of rules for different forms of access. Alternately, data stores can be
developed that have a simpler set of rules and provide faster data access.

http://article.gmane.org/gmane.comp.web.dojo.devel/8404

I'll have to digest all this information, but it still seems that this really can be turned it something useful, like a widget type with "observablePropertiesInTemplate" property to switch on the magic.

I'd like to hear more ideas on the topic.

I took this experimental 'observable' class on a test drive and I edited my sample to take advantage of that. Now we get "nice" setters (w1.f.foo = 'new value') also for IE.
(In order to test this, you need to fetch observable from the issue mentioned above.)

Now that Dojo 1.2 defines the standard interface for setting/getting all widget attributes, I figured that it would be the right time to update this page to include official Dojo-way of binding widget values to template elements: attr(). Instead of updating values via native setters (that's the thing in the samples above w1.foo = 'assigned a new value';), in Dojo 1.2 we do it with the help of attr(): w1.attr('foo', 'assigned a new value');