Try innerHTML in Widget.attr()

[Jarrod Carlson]

I noticed that _Widget.attr() calls _Widget._getAttrNames() to get a list of getter, setter, and node name to try. However, the attr() method as far as I can tell, never attempts to use the node (names.n).

Since the functionality is already there, I humbly propose a minor patch to _Widget that would allow it to set innerHTML on a DOME node as an additional attempt in setting an attribute.

Assume my Widget's template includes:

<span dojoAttachPoint="fooNode"></span>

The proposed changes would allow this code to work by default:

myWidget.attr("foo", "Bar");

The fooNode's innerHTML would be set to "Bar".

Please see the attached patch.

[Jarrod Carlson]

Allows Widget to look for an attachment point to try the innerHTML in attr()

[Jarrod Carlson]

allow it to set innerHTML on a DOME node as an additional attempt in setting an attribute.

allow it to set innerHTML on a DOM node as an additional attempt in setting an attribute.

[bill]

This functionality was in the original attr() patch of #7244, but I removed it because existing templates had tags with dojoAttachPoint="fooNode" but with no intention of mapping this.foo to fooNode.innerHTML.

It is possible to map this.foo to fooNode.innerHTML by adding an entry to attributeMap, but I don't want to do it "magically" as a result of domNode="fooNode", although of course I do see the convenience of it.

BTW, one other reason not to do it this way is that it's unclear if this.foo should be interpreted as HTML or plain text.

[Jarrod Carlson]

I see. Makes sense. I have a widget that will be mapping template nodes to an incoming JSON object, so doing this makes it much easier to accomplish my goal.

Perhaps a better use would be to create a sub-class of _Templated so that all a designer needs to do is create a template.

I want to be able to do the following:

var data = {
  foo: "bar",
  baz: {
    abc: "hello",
    def: "2009-01-01T18:00:00Z"
  }

myWidget.attr("value", data);

The widget should be smart enough to use the incoming data object as the "model" for any template nodes who's name or attachment point is a valid property of the data object:

<span field="foo"></span>
<span field="baz.abc"></span>

The widget should also still support normal attr() usage, so myWidget.attr("baz.def", "something") should still work, setting the innerHTML of the "baz.def" node, if it exists. This also allows setter methods to exist and do custom work. For example:

"_setBaz.defAttr": function(val) {
  this["baz.defNode"].innerHTML = dojo.date.stamp.fromISOString(def);
}

I have something in the works, and perhaps when I get it further along I'll submit it for consideration.

Thanks.

[Jarrod Carlson]

Basically I want the "set value" functionality of the _FormMixin, but for a read-only widget with no form elements.

[bill]

OK, thanks, I agree that maybe a subclass of _Templated is appropriate (or maybe another mixin)... it will be interesting to see what you come up with.

But note that the DTL code (in dojox) already supports the kind of thing you want... all the information about widget attribute mapping is encoded into the template, including mapping to DOMNode attributes and mapping to innerHTML.

Perhaps a better use would be to create a sub-class of _Templated so that all a designer needs to do is create a template.

Maybe I missed something but I don't understand how this would map widget attributes to DOM node attributes, without custom setters or attributeMap?

[Jarrod Carlson]

Bean Mixin

[Jarrod Carlson]

Sample Template

[Jarrod Carlson]

Bill, thanks for the pointers. I'll take a look at dojox.dtl, but my gut tells me it's way overkill for my simplistic needs. I've only been at Dojo for about four weeks, and I'm blown away by how expansive the Dojo universe it.

I attached a sample of what I'm working on. Put simply, the _BeanMixin lets me create new widgets with optional attribute setters. The _BeanMixin scans my template and grabs any nodes that name a data field. Then, when the widget is given a data "value", the _BeanMixin attempts to set the bean-style data fields against the template. Normal attributeMap and attribute setter methods are supported, so, for example, if I want to format a date, my custom widget can provide a _setDateAttr method to handle that.

Take a look, see what you think.

[Jarrod Carlson]

The main advantage here is that the _BeanMixin is providing a way of setting all the desired domNode attachment points from a single attr("value", value) call. There's no need to iterate over all the setters you want to call for a given data object instance.

This would be useful if your incoming data value was from a cross domain source that you don't have control over - a REST service, for example. Now getting a single JSON root object is easily mapped into a template.

[bill]

I see. It's interesting. You are basically moving some of the attributeMap data into the template.

I've always had mixed feelings about attributeMap as it does seem error prone to separate that information from the template, although there was a reason for it: to support inheritance (or something like inheritance) so that a subclass could reference the attributeMap from the superclass rather than repeating all that information.