PDA

View Full Version : [OPEN] [#413] // Remark in javascript in a DirectEvent Loaded UserControl causes SyntaxError: missing } after property list



michaeld
Jan 02, 2014, 8:41 AM
This code inside ascx control that is Rendered during a DirectEvent


<ext:Container ID="Cont" runat="server" Flex="1">
<HtmlBin>
<script type="text/javascript">
var Map = {
map: function (center) {
var mapOptions = {
center: center //new google.maps.LatLng(this.center[0], this.center[1])
};
}
};
</script>
</HtmlBin>
<Items>
<ext:Label ID="Label1" runat="server" Html="Inner" />
</Items>
</ext:Container>


I'm assuming the issue is the exclusion of a newline. It does not occur if wrapped in /* */

Vladimir
Jan 02, 2014, 8:08 PM
When control is rendered dynamically (during direct event) then generated javascript code is converted to single line to be returned in ajax request body
Therefore single comments cannot be used in javascript

I don't see yet how we can automatically resolve it. At this moment you have to use /**/ comments

michaeld
Jan 03, 2014, 1:28 AM
When control is rendered dynamically (during direct event) then generated javascript code is converted to single line to be returned in ajax request body
Therefore single comments cannot be used in javascript

I don't see yet how we can automatically resolve it. At this moment you have to use /**/ comments

Just noting the issue and the same resolution was found as well. However, I do not understand why these have to be converted to a single when SourceFormatting=true. It really makes debugging client-side Responses quite painful without breakpoints. Is there any reason you cannot maintain the existing newlines in htmlbin sections with this simple conversion?

http://stackoverflow.com/questions/42068/how-do-i-handle-newlines-in-json (http://stackoverflow.com/questions/42068/how-do-i-handle-newlines-in-json)

Vladimir
Jan 04, 2014, 5:25 AM
Generated javascript (from ajax request) is executed in 'eval' method
Try to run the following code


eval("alert('one');//sometext\\n\\n alert('two')")


You will see only first alert

michaeld
Jan 04, 2014, 6:33 AM
Generated javascript (from ajax request) is executed in 'eval' method
Try to run the following code


eval("alert('one');//sometext\\n\\n alert('two')")

You will see only first alert

Valid point, do you mind sharing where I can find the code that removes the newlines? I'd still like to have newlines in my eval'd code so I can console.break() on lines. Somewhere these \n's are being stripped from the ITemplate HtmlBin, and I'd like to look under the hood. It seems to me remarks could be removed too with a little smarts.

Daniil
Jan 06, 2014, 2:36 PM
We discovered that this works:

eval("alert('one');//sometext\n\n alert('two')")

Also the following works during a DirectEvent.

X.Js.AddScript("alert('one');//sometext\n alert('two');");

So, the issue happens while rendering HTML. It is done in Core\BaseControl\Lifecycle.cs, line #1110:

string[] lines = html.Split(new string[] { "\r\n", "\n", "\r", "\t" }, StringSplitOptions.RemoveEmptyEntries);

At least, it was done to reduce traffic and improve formatting of the output. Maybe, something else. I don't know for 100%. Unfortunately, the issue with "//" arises with that approach.

So, from one side we have "reduce traffic" and "better formatting", and "break due to JavaScript" from another side.

Though, as far as we can remember you are the first one who caught it.

Anyway, we should review it, at least, for v3.
https://github.com/extnet/Ext.NET/issues/413

Thank you for the request.

michaeld
Jan 07, 2014, 2:37 AM
At least, it was done to reduce traffic and improve formatting of the output. Maybe, something else. I don't know for 100%. Unfortunately, the issue with "//" arises with that approach.

Totally understandable. Small footprints make sense. However, so does the need for debugging in debug cases. Just like in SourceFormatting setting in ResourceManager, it's important to be able. So beyond the topic of this bug which is easy to work around, I'm far more interested to find out if you intend to allow us to keep our formatting in the htmlbins of client-side evals. You didn't mention if you'll be able to support this in the future.


So, from one side we have "reduce traffic" and "better formatting", and "break due to JavaScript" from another side.
Yes, the option to choose would be lovely.

Daniil
Jan 07, 2014, 12:55 PM
So beyond the topic of this bug which is easy to work around, I'm far more interested to find out if you intend to allow us to keep our formatting in the htmlbins of client-side evals. You didn't mention if you'll be able to support this in the future.

At the first glance we don't see a clear way to achieve that. Hopefully, there is a way.

michaeld
Jan 27, 2014, 7:05 AM
So I found there is a case where the eval'd script contains proper newlines. The case in which they do is when I have newlines in the handler of a listener for a control.

So there is a way to get the newlines.
Example:


<TriggerClick Handler="
switch(index) {
case 0: ZRScope.remove();break;
case 1: ZRScope.select(#{Ctl1});break;
}" />

... constructs this response:


...
,triggerclick:{fn:function(item,trigger,index,tag, e){\r\n\t\t\t\tswitch(index) {\r\n\t\t\t\tcase 0: ZRScope.remove();break;\r\n\t\t\t\tcase 1: ZRScope.select(App.ctl00_cp_id48514cc72cea7578_id2 a0eed021ddb6e68_Ctl1);break;\r\n\t\t\t\t}}}

which invokes a VM5401 with:


...
triggerclick:{fn:function(item,trigger,index,tag,e ){
switch(index) {
case 0: ZRScope.remove();break;
case 1: ZRScope.select(App.ctl00_cp_id12a669fc700a792f_idd a3d5f32b658421f_Ctl1);break;
}}},...


Clearly there is a difference between the preprocessing happening in an HtmlBin that is different than a Listener.Handler so I think there are clues this isn't such an unattainable goal. Moreover, I hope it means we can enforce SourceFormatting only when true on DirectEvent/Method responses.

Daniil
Jan 27, 2014, 11:13 AM
Yes, a good catch. Thank you for the notes!

Yes, the goal should be attainable.