We Keep Coding

Why jQuery-migrate in not replacing depreciated functions directly in the code?

Im using jQuery-migrate on a big project. I corrected all the warnings I could but now the warnings are inside libraries.
Some libraries are not updated anymore so I can't update them to make them work with jQuery-3.3.1.
Also, I can't replace the depreciated functions directly in the libraires because it is creating errors.
So I think that I'll keep jQuery-migrate in my project.
My question is : If jQuery-migrate is able to correct the depreciated functions when called, why it can not correct them directly in the code ?

JavaScript does not lend itself to static code analysis.
Say you needed to replace the foo function.
That would be fairly trivial if the code that called it was simply:
something.foo();
It becomes rather harder if it is:
function call(bar, method) {
bar[method]();
}
call(something, "foo");
… and even harder if the logic needed to get there was more complicated.
Creating something.foo so it just exists if anything try to access it at runtime is much simpler.

is it possible to obfuscate while using soma.js dependency injection?

While looking at how to make JavaScript source code more secure I came upon a lot of 'solutions'. but most people said the same thing; "It's not possible to make your source code 100% secure", "try obfuscation", "run your code server side", etc, etc. After reading a lot posts here on stackoverflow, and other sites I came to the conclusion that a combination of minifying and obfuscating would do the job (for me).
But here is the problem: we are currently using soma.js with dependency injection, and the way we set it up it does not work well with obfuscation. It's basically this:
var session = function(id, sessionModel){
this._sessionmodel = sessionModel;
}
mapping:
injector.mapClass("sessionModel", project.SessionModel, true);
Obfuscation will then rename the sessionModel in the function to for example 'A', but the mapping that was done on SessionModel by the injector still remains 'sessionModel' and not 'A', this then basically breaks the code.
I've read this post which is about the same subject Dependency Injection and Code Obfuscation, but it does not provide a real answer to my problem so I decided to write my own question.
Any tips/hint/suggestions are welcome.
Thanks in advance.
EDIT
It seems you can tell Yuicompressor to exclude certain identifiers by putting in 'hints' into the files like this: "identifier:nomunge, identifier2:nomunge".
var session = function(id, sessionModel){
"sessionModel:nomunge";
this._sessionmodel = sessionModel;
}
I tested this and it works but that means you'll have to put it in yourself which is a lot of work if you have to do that for every script, especially if you have a very big project..
Gonna look into it further, and update this post if anything new pops up
EDIT 2
It's been a while, I only work 1 day a week on this =S.
As said before you can get it working by telling it which identifiers to exclude.
For that I looked into regular expression to get the "mapped classes" programmatically, since doing it by hand is just insane.
What I basically did was instead of putting every hint in by hand, I made a identifier, for example "#nomunge"; and used a simple replaceregexp task to find it and replace it with a string containing all the identifiers. This string is build by loading the script and going through it with a tokenfilter.
<target name="build hints">
<loadfile property="hints" srcFile="${temp.loc}/all.js">
<filterchain>
<tokenfilter delimoutput=":nomunge,">
<ignoreblank/>
<containsregex pattern="${regexp}"/>
</tokenfilter>
</filterchain>
</loadfile>
<echo message="${hints}"/>
</target>
<replaceregexp file="${temp.loc}/all.js"
match="#nomunge"
flags = "g"
replace = "target:nomunge, dispatcher:nomunge, injector:nomunge,${hints}"
/>
This seems to do the job, for now...

I'm behind the soma.js framework, feel free to ask me questions on the google group, happy to help.
This might help a bit more:
https://groups.google.com/forum/#!topic/somajs/noOX2R4K58g
Romu

spellchecking code comments in Textmate

Does anyone know of a plugin I can use to spell check the comments in my code?
I'm always doing things like this
//Retrns porduct name in upercase
function getUpperCaseProductName(){
var productName = Myobj.currentProduct.data.name;
return productName.toUpperCase();
}

I don't know of a textmate plugin, but I'm pretty sure it does this already via Edit → Spelling, which is enabled by default for comments. Start by checking that you don't have this turned off for comments, or set to the wrong language.
It's unlikely that someone will develop a custom plugin to do something that textmate already has as a feature.
BTW, the //Retrns example you give above is joined to the two slashes. No word in the dictionary has two slashes at the start, so it may be missing it for this reason. If this is the problem, file a bug report with the textmate guys, or perhaps consider moving to a more feature-rich editor if it bothers you a lot (PHPStorm picks up that typo just fine, and you can also check the names of variables and functions if you want to be really pernickety).

Try using the Spelling option under Edit in Textmate2.
I think it does not differentiate between code and comment for Spell Check.

Is Annotation in Javascript? If not, how to switch between debug/productive modes in declarative way?

This is but a curious question. I cannot find any useful links from Google so it might be better to ask the gurus here.
The point is: is there a way to make "annotation" in javascript source code so that all code snippets for testing purpose can be 'filtered out' when project is deployed from test field into the real environment?
I know in Java, C# or some other languages, you can assign an annotation just above the function name, such as :
// it is good to remove the annoying warning messages
#SuppressWarnings("unchecked")
public class Tester extends TestingPackage
{
...
}
Basically I've got a lot of testing code that prints out something into FireBug console.
I don't wanna manually "comment out" them because the guy that is going to maintain the code might not be aware of all the testing functions, so he/she might just miss one function and the whole thing can be brought down to its knees.
One other thing, we might use a minimizer to "shrink" the source code into "human unreadable" code and boost up performance (just like jQuery.min), so trying to match testing section out of the mess is not possible for plain human eyes in the future.
Any suggestion is much appreciated.

You can overwrite the Firebug console functions so they do nothing:
console.log = function() { };
You could perhaps include this into your code in your build process.

prototype and jQuery peaceful co-existence?

I know very little about JavaScript but despite this I'm trying to cobble something together on my wordpress blog. It's not working, and I don't know how to resolve it, and hey, that's what StackOverflow is for, right?
Firstly, the error message is:
Error: element.dispatchEvent is not a function
Source File: http://.../wp-includes/js/prototype.js?ver=1.6
Line: 3936
It happens on page load. My page load handler is registered thusly:
Event.observe(window, 'load', show_dates_as_local_time);
The error goes away if I disable some other plugins, and this (plus googling) led me to conclude that it was a conflict between prototype and jQuery (which is used by some of the other plugins).
Secondly I'm following the wordpress recommended practice of using wp_enqeue_script to add a dependency from my JavaScript to the Prototype library, as follows:
add_action( 'wp_print_scripts', 'depo_theme_add_javascript' );
function depo_theme_add_javascript() {
wp_enqueue_script('friendly_dates', 'javascript/friendly_dates.js', array('prototype'));
}
Now I'm also aware that there are some potential conflicts between jQuery and Prototype which are resolved using the jQuery noConflicts method. I've tried calling that from various places but no good. I don't think this is the problem because a) the noConflict function relates solely to the $ variable, which doesn't seem to be the problem here, and b) I would expect wordpress to sort it out for me because it can...
Lastly, using the Venkman debugger I've determined that the element referenced in the error message is indeed an HTMLDocument but also does lack a dispatchEvent. Not sure how this could happen, given it's a standard DOM method?

There is a nasty trick many libraries do that I've taken a distinct liking to, and it looks like prototype is one of these.
Mootools does this, If I am right, and it involves overloading many of the prototypes on the basic classes, monkey patching them.
And likewise, I similarly encountered strange behaviour when mootools and jQuery were present, usually jQuery dying because it was calling some object method which had been somehow overloaded/monkey patched by Mootools.
Also, mysteriously, taking mootools out of the script usage list, resulted in everything running much faster, which I concluded was due to less object pollution.
Now I could be wrong, but I concluded from my experience such libraries just simply don't like to co-exist with each other, and seeing how mootools code seemed to me to degrade speed at which normal things were done, I sucked up and ported all mootools based code to jQuery ( A time consuming deal I assure you ), and the result, was code that was fast and didn't have weird errors that were unexplainable.
I recommend you consider migration as at least One of your options.
One More thing, when writing:
I tend to use this syntax with all my jQuery driven code, for a bit of safe encapsulation in the event somebody breaks '$' somehow.
Runtime Code
This waits for document.ready before executing:
jQuery(function($){
code_with_$_here;
});
jQuery Plugins
(function($){
code_with_$_here;
})(jQuery);
Using these will make it easier for people using any jQuery you happen to write to be able to use it without much of a conflict issue.
This will basically leave them to make sure their code isn't doing anything really magical.

Its worth reading this article on the JQuery site about Using JQuery With Other Libraries. It deals with more than just the noConflict option.

I think you should search well because all jQuery plugins has a prototype version and all prototype plugins has a jQuery version.
If you really don't find what you look and you can't use only one library, take a look here at
jQuery.noConflict();
But again, i think it make no sense to load over 15-20kb for each library :)

Thanks for the suggestions all. In the end I think Kent's explanation was the closest, which basically amounted to "Prototype is broken". (Sorry if I'm summarizing you incorrectly :)
As for the jQuery.noConflict option - I already mentioned this in the question. It makes a difference when you run this method, and I have very little control over that. As I said, I have tried running it in a couple of different places (specifically the page header and also from my script file), to no effect. So, much as we'd all like it to be, "just use noConflict" is not an answer to this question, at least not without additional information.
Besides, jQuery.noConflict seems to be about the $ variable, and the code around the error point does not deal with that variable at all. Of course they could be related indirectly, I haven't tracked it down.
So basically I ended up rewriting the script using jQuery instead of Prototype, which actually had its own problems. Anyway I've published the whole war story on my blog, should you be interested.