Opened 8 years ago

Closed 4 years ago

#14631 closed task (invalid)

Parser Unit Test Coverage

Reported by: Kitson Kelly Owned by: Kitson Kelly
Priority: high Milestone: 1.13
Component: Parser Version: 1.7.1
Keywords: Cc:
Blocked By: Blocking:

Description

This ticket is to track coverage of the dojo.parser unit test scenarios. The following scenarios are not covered by the current unit test:

1 - Instantiating an Object and then Referencing Object

There is no test for the following scenario, where a global variable is set for an object and then it is referenced later on:

  <div data-dojo-type="dojo.data.ItemFileReadStore" data-dojo-id="myStore"></div>
  <div data-dojo-type="..." data-dojo-props="store: myStore"></div>

2 - Changing the scope

There is no test for changing the scope from a default of dojo. For example, the following should work:

parser.parse({
  scope: "myScope"
});
<div data-myScope-type="..." data-myScope-props="..."></div>

3 - Using "with" in declarative scripts

This is also currently an undocumented feature and does not support an HTML5 compliant attribute specification, but irrespective of that, there is no unit test case for something like this:

<div data-dojo-type="dojo/form/Button" id="button1">Button 1
  <script type="dojo/connect" data-dojo-event="onClick" with="myVar1, myVar2">
    ...
  </script>
</div>

4 - Testing specifically for the template argument

There is no specific test for passing the args.template argument, which is used by some dijits to ensure their templates are parsed even if they contain widgets that indicate they shouldn't be. Like the following should be fully parsed and instantiated, instead of stopping at the ContentPane?:

parser.parser{
  template: true
});
<div data-dojo-type="dijit/layout/ContentPane">
  <div data-dojo-type="dijit/form/Button">Button</div>
</div>

5 - Testing for passing args without rootNode

There is no specific test for just passing the args parameter without the rootNode parameter. There should be at least 6 different scenarios tested:

parser.parse();

parser.parse(dojo.byId("myId"));

parser.parse{{
  rootNode: dojo.byId("myId")
});

parser.parse({
  scope: "myScope",
  rootNode: dojo.byId("myId")
});

parser.parse(dojo.byId("myId"),{
  scope: "myScope"
});

parser.parse({
  scope: "myScope"
});

Change History (8)

comment:1 Changed 8 years ago by bill

Wow, didn't even know about that "with" parameter. I guess no one else knew about it either, otherwise we would have changed it to data-dojo-with.

comment:2 Changed 8 years ago by Kitson Kelly

6 - Mixed Case of "special" attributes and mapped attributes

There are no tests that test for mixed case of special attributes like jsId or dojoAttachPoint or data-dojo-props. Also, attributes that get mapped to prototypes can have mixed case, in that ONCLICK or onclick or oNcLiCk all get mapped to onClick. For example all the following are valid:

<div JSID="myId" dojoType="..."></div>

<div JsId="myId" dojoType="..."></div>

<div jsid="myId" dojoType="..."></div>

<div data-dojo-type="..." ONCLICK="myFunction"></div>
Last edited 8 years ago by Kitson Kelly (previous) (diff)

comment:3 in reply to:  2 Changed 8 years ago by bill

Replying to kitsonk:

6 - Mixed Case of "special" attributes and mapped attributes

There are no tests that test for mixed case of special attributes like jsId or dojoAttachPoint or data-dojo-props. Also, attributes that get mapped to prototypes can have mixed case, in that ONCLICK or onclick or oNcLiCk all get mapped to onClick.

Hmm, well IIRC that's there because some browsers operate case-insensitively, so that <div jsid="myId" ... gets reported as JSID or jsid. In other words, the code in the parser is to work around browser issues rather than to allow users to specify whatever case they want.

So not sure if variable case is something we want to support explicitly or not.

comment:4 Changed 8 years ago by Kitson Kelly

7 - Specific testing for context of data-dojo-props and object attribute values

The parser supports args.propsThis and there are specific tests for this for _WidgetsInTemplate mixin unit test, but the parser unit test doesn't specifically test for this, and currently the parser supplies the context when evaluating data-dojo-props but doesn't do the same when converting other attributes that might be a JavaScript object being passed.

Something like the following:

parser.parse({
  propsThis: this
});
<!-- This works currently -->
<div data-dojo-type="..." data-dojo-props="myObjProp: this.myObj"></div>

<!-- This doesn't work currently -->
<div data-dojo-type="..." myObjProp="this.myObj"></div>

comment:5 Changed 8 years ago by Kitson Kelly

8 - Testing for args.defaults

Another feature that doesn't appear in the API documentation is the support for args.defaults as an object that is mixed into the object before it is instantiated. (Note: should check to see if anything actually uses this and seems redundant with the mixin functionality)

The code supports the following:

parser.parse({
  defaults: {
    myProp: "myValue"
  }
});

comment:6 Changed 8 years ago by Kitson Kelly

9 - Attributes that are URLs and Objects

The parser can map both URLs and Objects passed as values of attributes to parameters passed on instantiation, but there are no tests for these. The following is valid according to the code:

<div data-dojo-type="..." objAttr="{item: 'prop'}" objUrl="apath/something.html">
</div>

comment:7 Changed 4 years ago by dylan

Milestone: tbd1.12
Owner: changed from bill to Kitson Kelly
Status: newpending

comment:8 Changed 4 years ago by trac-o-bot

Resolution: invalid
Status: pendingclosed

Because we get so many tickets, we often need to return them to the initial reporter for more information. If that person does not reply within 14 days, the ticket will automatically be closed, and that has happened in this case. If you still are interested in pursuing this issue, feel free to add a comment with the requested information and we will be happy to reopen the ticket if it is still valid. Thanks!

Note: See TracTickets for help on using tickets.