Dojo parser for data-dojo-props should accept object string with braces

[Mark DeMichele]

I'm using JSON.NET to build data-dojo-props from the server with C# code. JSON.NET has almost all the features to build a string compatible with data-dojo-props. The only thing I can't seem to control is supplying the outside braces which makes sense. JSON.NET is serializing an Object and an Object has braces so I wind up with strings like,

data-dojo-props="{prop1:'xxx', prop2:true, prop3: { subprop1: 123 } }"

I looked at the dojo parser code and it's pretty straight forward.

extra = djson.fromJson.call(options.propsThis, "{" + extra + "}");

The code is blindly adding the braces to the attribute value. If the code would just check first and only add them if necessary it would solve my problem. Is there any chance to get a change like this. I don't see the harm. I think you're already doing similar stuff with dom-construct when looking at strings and determining if they are IDs or HTML.

[ben hockey]

could you manipulate the string on the server-side to remove the first and last char? pushing extra work to the client affects every user of dojo and the performance of the parser is relatively critical - the less it does, the better.

[bill]

You could also manipulate it on the client side, something like

query([data-dojo-props]).forEach(function(node){
   var old = node.getAttribute("data-dojo-props");
   node.setAttribute("data-dojo-props", old.substring(1, old.length-1);
});

[trac-o-bot]

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!

[Mark DeMichele]

I appologize for not getting back. I must have missed the notification e-mail and forgot all about this. To answer your question, I did in fact add the removal on the server side. It just seemed wasteful that way since I'm using JSON.Net to build it and it puts in the {} and then I just go and remove them. This puts a extra load on my server that will serve many requests. From my point of view, I try to push as much stuff to the client as possible since the client is more scalable then the server since it's distributed among each user.

My logic for the change is this. data-dojo-props is effectively a JSON string. I would imagine that most server frameworks will support creating that string from an object, and I would also think that since it's an object, the framework will enclose the string in {} similar to JSON.net. So I figured dojo should handle that case. Since dojo has code all over the place to check for strings or objects to do different things, I thought one more "if" in that parser code wouldn't be a big deal,so I figured I would ask.

Just something to think about.

[bill]

I don't care either way. Kitson may have an opinion. If we allow it for data-dojo-props though we should also allow it for data-dojo-config (on the <script src=".../dojo.js" data-dojo-config="..."> line), for consistency.