Closed aaronsofaly closed 11 years ago
Could you provide more context of why you are using the depreciated caller function?
The "use strict" is not just for jslint compliance and is part of the ECMAScript 5 language in order "to protect you from the more perilous aspects of the language."
http://javascriptweblog.wordpress.com/2011/05/03/javascript-strict-mode/
That's not my code.
It's the code for window.API_1484_11.GetValue()
that Pegasus uses. The GetValue()
method raises an exception because it is trying to call a function that is in strict mode.
Using "use strict";
is just fine for code that you control. However, it has potential to break things when used with 3rd party code like what is happening here with the Pegasus code.
So is the LMS trying to call a function on the content side? This would indicate that the LMS is initiating the communication which is not allowed according the SCORM Specification.
If this is the case, then this is exactly the sort of back door communication that "use strict" is supposed to prevent.
Aaron, Thanks for bringing this up. Its interesting they are looking into those depreciated methods, or more importantly what they are doing with them. I could speculate, but I would almost consider this a mexican standoff. We could remove it, but as as far as the whole modern coding principles I lose quite a bit from a development standpoint. The person deploying could remove the "use strict" themselves, and release to cope with there concerns. Or the LMS could remove depreciated code.
I will look into what pitfalls there are using "use strict"
in development and then removing it in a release. What would this approach cause, etc...
The main point of this definitely wasn't just for JSLint approval, it was mostly to stop implicitly declared variables, 'eval' and 'with' etc ... this site essentially sums it up by brandon's mentioned of perilous aspects of the language. http://msdn.microsoft.com/en-us/library/ie/br230269(v=vs.94).aspx
I've also noted when doing a separate project were I fire off thrown errors to a central server (specially when deploying SCO's into the wild) you don't always get all the feedback about 404's and JS Errors. So I had similarly attempted to check arguments.callee.caller and ran into the same thing.
Thanks, Mark
@brandonbradley Pegasus is using arguments.callee.caller
because it's trying to get the name of the function that called the GetValue()
method. It then checks to see if that function is an internal Pegasus function and if it is then it fires off a different function.
By no means do I endorse anything Pegasus does, lol.
@cybercussion You can leave "use strict";
. I am bringing this issue to your attention so that you can make a decision on LMS compatibility.
I have to support Pegasus, so for my purposes I will remove "use strict";
.
Aaron, I appreciate it, its a interesting issue that hadn't come up previously. I have the same dilemmas about the few dangling strings relying on JQuery too. Specially if the project didn't previously use that framework. The modernization apparently does come at a price, but at least there is a workaround.
Let me know if removing "use strict"
has any adverse effects after you get a chance to run it.
Will do.
"use strict";
causes a 301 error in Pegasus when using Chrome.I snooped around and looked at the source code for the
window.API_1484_11
object that Pegasus uses. This is the snippet for theGetValue()
method:What happens is
arguments.callee.caller
raises anUncaught TypeError: Illegal access to a strict mode caller function.
exception in Chrome. Pegasus is trying to call the caller function but since that function is in strict mode it raises an exception. The catch catches the exception and returns the 301 error code.The recommended solution would be to remove the
"use strict";
declaration so that the Scorm API is compatible with different LMS environments. I understand you want to be jslint compliant but that compliance hinders compatibility.