Opened 11 years ago

Closed 11 years ago

Last modified 11 years ago

#8970 closed enhancement (wontfix)

Try innerHTML in Widget.attr()

Reported by: Jarrod Carlson Owned by:
Priority: high Milestone: tbd
Component: Dijit Version: 1.3.0b3
Keywords: widget dom attr Cc:
Blocked By: Blocking:

Description

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.

Attachments (3)

_Widget.js.diff (496 bytes) - added by Jarrod Carlson 11 years ago.
Allows Widget to look for an attachment point to try the innerHTML in attr()
_BeanMixin.html (5.1 KB) - added by Jarrod Carlson 11 years ago.
Bean Mixin
MyTemplate.html (1.5 KB) - added by Jarrod Carlson 11 years ago.
Sample Template

Download all attachments as: .zip

Change History (11)

Changed 11 years ago by Jarrod Carlson

Attachment: _Widget.js.diff added

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

comment:1 Changed 11 years ago by 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.

comment:2 Changed 11 years ago by bill

Resolution: wontfix
Status: newclosed

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.

comment:3 Changed 11 years ago by 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.

comment:4 Changed 11 years ago by Jarrod Carlson

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

comment:5 Changed 11 years ago by 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?

Changed 11 years ago by Jarrod Carlson

Attachment: _BeanMixin.html added

Bean Mixin

Changed 11 years ago by Jarrod Carlson

Attachment: MyTemplate.html added

Sample Template

comment:6 Changed 11 years ago by 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.

comment:7 Changed 11 years ago by 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.

comment:8 Changed 11 years ago by 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.

Note: See TracTickets for help on using tickets.