Decrease wordiness in declarative format about d2-proto

[kitsonk]

My only concern is that the attribute names have been out there for a while, and I wouldn't want to support two sets of attribute names (dropping the deprecated dojoType to have it replaced by a deprecated data-dojo-type seems silly).

I guess if we are breaking back-compat with 2.0, then we could break it.

The one argument I have seen for data-dojo-type is that in theory the middle could be changed so that the parser would recognise data-dojo16-type for example and multiple versions of the parser could be run on the same page, without stepping on each other. I am not wholly convinced of that though.

As far as working with the jQuery team, I wouldn't say no, but I personally don't know the right person to talk to about that.

[wkeese]

Sounds like $() all over again, where jQuery uses the convenient non-namespaced short variable name whereas dojo took the high road.

[kitsonk]

Ok, I have added a feature to the parser that sort of addresses this. It allows the invoker to specify alternative attributes as options, which then persist for as long as that parser persists or until changed again. So for example to use data-type, data-props and data-id and data-mixins:

require(['d2-proto/parser'], function (parser) {
  parser.parse({
    typeAttribute: 'data-type',
    propsAttribute: 'data-props',
    jsIdAttribute: 'data-id',
    mixinsAttribute: 'data-mixins'
  });
});

Also, because this parser uses querySelectorAll to retrieve DOM nodes that are decorated for instantiation, the caller can override that as well. The default will be '[' + typeAttribute + ']', but something more clever could be supplied, like if the developer only wanted to instantiate nodes that also had a data-touchme attribute as well, they would do something like this:

require(['d2-proto/parser'], function (parser) {
  parser.parse({
    typeAttribute: 'data-type',
    typeSelector: '[data-type][data-touchme]'
  });
});

[wkeese]

Oh I forgot that the parser is like a singleton. That makes implementing this nasty. It would be cleaner if the API was something like:

new Parser({
    typeAttribute: 'data-type',
    typeSelector: '[data-type][data-touchme]'
}).parse();

Cleaner code-wise, but more trouble for the user, so I guess it's a toss-up.

[wkeese]

PS: On a more practical level, this "once values are set, they are persisted until set again" strategy will break any code that assumes the parser is searching for data-dojo-type etc. For example, _WidgetsInTemplateMixin. It would make more sense IMO for the code below to not have any side effects:

parser.parse({
    typeAttribute: 'data-type',
    typeSelector: '[data-type][data-touchme]'
}); 

[kitsonk]

Ok, this needs some rethinking. I like the singleton nature of the parser. In fact, I was half minded to return a decorated function so that:

parser();

Is the equivalent to:

parser.parse();

The problem I was trying to solve was the old problem of using a different set of tags for a different parser (like running two different version of Dojo on a page), and if it didn't persist between parses then what would happen is any content loaded by a ContentPane type of widget would revert back to the non-custom attributes, but obviously that then causes issues with other code that expects standard attributes that leverage the same parser.

Maybe a partial solution is that options passed on the parser.parse() do not persist, but there is a parser.configure() which then persists those options, with the knowledge that all parses will then use those, unless they override them on the individual invocation.

Another thought is that the template flag will always revert to the standard attributes, that way, developers could write templates knowing they will get parsed consistently.