Opened 7 years ago

Closed 7 years ago

Last modified 7 years ago

#16590 closed enhancement (invalid)

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

Reported by: Mark DeMichele Owned by: Mark DeMichele
Priority: undecided Milestone: tbd
Component: Parser Version: 1.8.3
Keywords: Cc: Kitson Kelly
Blocked By: Blocking:

Description

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.

Change History (5)

comment:1 Changed 7 years ago by ben hockey

Owner: changed from bill to Mark DeMichele
Status: newpending

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.

comment:2 Changed 7 years ago by 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);
});

comment:3 Changed 7 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!

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

comment:5 Changed 7 years ago by bill

Cc: Kitson Kelly added

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.

Note: See TracTickets for help on using tickets.