We Keep Coding

Trying to avoid multiple calls to jQuery in a Domino XPage

I am attempting to use the 'DataTables' table plug-in for jQuery on a simple Domino XPage.
I have loaded the two required libraries from CDN's...
JQuery: ajax.googleapis.com/ajax/libs/jquery/1.12.4/jquery.min.js
DataTables: cdn.datatables.net/1.10.13/css/jquery.dataTables.min.css
I have also tried loading them from local resources (doesn't help).
I then prepare a basic table on my XPage, and include the necessary Javascript to initialise the table...
$(document).ready(function() {
    $('#tableID').DataTable();
} );
When I test the XPage, I continually observe
test.xsp:15 Uncaught TypeError: $(...).DataTable is not a function
I've searched through several forums, and the general consensus is that...
a) I have loaded the libraries in the wrong order (nope!)
b) I have loaded jQuery more than once (how?)
I have many other solutions using Bootstrap and jQuery, and have never run into this issue before. So, I though I might strip the XPage back to bare bones. I got rid of all Dojo elements on the page by adding the following line to the 'xp.properties' file...
xsp.client.script.libraries=none
That actually seemed to work! I no longer observed the error. However, my page no longer looked like it should (for obvious reasons!). I've had to restore the 'xp.properties' file back to its original state, but cannot find out how to avoid the error.
Has anyone successfully used the 'DataTables' jQuery plug-in on an XPage? Any feedback or suggestions would be most appreciated!

Yes I have been doing a load of work on DataTables in XPages so it definitely works! I know your pain though....
The order of your jquery scripts in relation to each other may be okay, however there is a clash with dojo and it's AMD loader, so you have 3 options.
Option 1. Load your jquery scripts before any of the xpages scripts
Option 2. remove the 'amd loader' just before your jquery scripts and then restore it just after
Option 3. modify the javascript of the datatables so it ignores the amd problem
Option 1 : Loading your jQuery scripts first
If you are using resource aggregation, you can use this tip from Sven Hasselbach's blog, in which you use the generic 'headTag' resource tag and it will load first.
http://hasselba.ch/blog/?p=1181
If you want a solution that will work regardless of resource aggregation setting, I have an example on my blog in which you can create a viewRootRenderer which will then allow you to specify that you want a script loaded BEFORE everything else
http://camerongregor.com/2016/09/19/controlling-the-order-of-script-resources-e-g-jquery-with-a-custom-viewrootrenderer/
Option 2. Removing the AMD loader before loading scripts
There is an xsnippet which explains how to remove and then restore the amd loader so that a jquery plugin will load
https://openntf.org/xsnippets.nsf/snippet.xsp?id=hack-to-use-jquery-amd-widgets-and-dojo-together
Sven had already made a similar solution to mine above (viewRootRenderer) in which you can specify which scripts will need the amd loader disabled and it will do this for you, it is available here
http://hasselba.ch/blog/?p=2070
Option 3 : modify javascript of the jquery plugin (datatables)
Mark Roden demonstrated this on his blog. I don't really like doing it but hey it works!
https://xomino.com/category/jquery-in-xpages/
Let me know if any of this works! I hope I'm right, with javascript I never know...

what is google map's javascript load strategy

When I use google maps, I am interested in its implemention, so I use the firebug to inspect.
Then I found that its javascript loading strategy is rather interesting. Take this page for example:
The overlay example
Then when I open this page first time, the following js are loaded:
https://maps.googleapis.com/maps/api/js?sensor=false
https://maps.gstatic.com/intl/en_us/mapfiles/api-3/9/13b/main.js
https://maps.gstatic.com/cat_js/intl/en_us/mapfiles/api-3/9/13b/%7Bcommon,map,util,poly%7D.js
https://maps.gstatic.com/cat_js/intl/en_us/mapfiles/api-3/9/13b/%7Bonion,geometry%7D.js
But if I refresh the page(use the ctrl+f5), the following js are loaded:
https://maps.googleapis.com/maps/api/js?sensor=false
https://maps.gstatic.com/intl/en_us/mapfiles/api-3/9/13b/main.js
However the page still works, the overlay is drawn in the map. But where is the poly.js and etc?
Also, can anyone tell me how to load the js by components? For exmaple the common util poly in the example.
What should I know when I write the different components?

1. When poly.js loads, it passes a string to google.maps.__gjsload___.
Here's an excerpt:
google.maps.__gjsload__('common', '\'use strict\';var Ai=isNa...
The rest of the file is just the contents of that string.
My hunch is this function probably stores this string in localStorage or sessionStorage so that it only has to be retrieved once.
2. Also, if you want to learn about loading js files as-needed, look into AMD and/or CommonJS:Modules.
A good imlementation of AMD (my preference) is RequireJS.
Update
I did some poking around, and localStorage and sessionStorage do not appear to be being used on this page. I also can't duplicate your results. In Firebug, poly.js always loads for me. There may be some magic happening somewhere, but I don't see it.
However, it's entirely possible to store a string in localStorage and sessionStorage for retrieval without having to make an extra js call.

Also,any one can tell me how to load the js by components?
this touches on the topic of asynchronous javascript file loading. if you've ever used a language that has a way to "include" a file at any point in a script, you'll understand that javascript does not have this capability. because of that, there is this whole paradigm of "aysnc javascript addition" via script tag injection.
script tag injection: you dynamically make a script tag, and set its source to the file you need, and insert that tag into the DOM, and voila, a new file has been loaded and executed. With javascript heavy applications, this is common, especially when loading third party applications. Google does it alllll the time, just check out google analytics' include script for a good example of this.
Now, since this is a touchy and delicate type of coding to do, some "javascript component / module / asset loading" frameworks have refined it and made it pretty stable. common.js, require.js, etc have all done good jobs at this.
What should I know when I write the different components ?
For what you're doing with google maps, you don't really need to know much. but if you get into javascript module pattern development, you need to know this: make sure you protect your global namespace from being cluttered by your own variables, so encapsulate all of your work in closures when possible, and (recommended but not required) start them all with a ; so they don't break each other if they get loaded out of order.

How to use javascript in Silverstripe CMS?

I'm using SilverStripe 3.0 CMS, and I need to include a Google Map into the CMS.
I'm following this steps, and besides it's a little bit old, the official documentation uses the same methods in the current version of SilverStripe (At least it seems to be the current version documentation).
The issue is in this part of the code:
Behaviour.register({
"#Form_EditForm" : {
initialize : function() {
this.observeMethod("PageLoaded", this.adminPageHandler);
this.adminPageHandler();
},
adminPageHandler : function() {
initialize();
}
}
});
First of all, Behaviour was not defined. I needed to include manually the behaviour.js file that comes within the framework. But now, I get a Type Error:
this.observeMethod is not a function
Can someone give me a hint of what can I do in order to call a javascript function when a page editor is opened in the SilverStripe CMS?

the 'Behaviour.register' call you mention is definitly deprecated and no longer available in the core code, so the docs need an update here.
unfortunately, i couldn't find a documented way to replace this behaviour, but for now the following should work for you, based on the approach in the forum post you mentioned first hand:
find the 'initGoogleMaps.js' script added here:
function getCMSFields() {
Requirements::javascript('mysite/javascript/initGoogleMaps.js');
...
inside this script, remove the Behaviour.register... block, and move the initialize function outside document.ready (or simply remove the document.ready part), so initialize is globally available (you might consider renaming it).
then, add the following inside getCMSFields:
$fields->addFieldToTab('Root.Content', new LiteralField('js', '<script>initialize();</script>'));
this will ensure the initialize function is called every time a page's 'edit view' is rendered inside the cms.
hth

As mentioned by ben,
LeftAndMain::require_javascript('mysite/javascript/initGoogleMaps.js')
is more reliable than 'include-it when needed'. Why?
Because Silverstripe uses Ajax, it is better to load any javascript or css on the first load, so that they are ready when you go to different model admin areas within the CMS in ajax-powered environment. Not loading at the start causes inconsistency and your js, css files will not be loaded when you don't hard-load that admin area.
From documentation: http://doc.silverstripe.org/framework/en/reference/requirements and http://api.silverstripe.org/3.0/class-LeftAndMain.html
The whole "include it when you need it" thing shows some weaknesses in
areas such as the CMS, where Ajax is used to load in large pieces of
the application, which potentially require more CSS and JavaScript to
be included. At this stage, the only workaround is to ensure that
everything you might need is included on the first page-load.
One idea is to mention the CSS and JavaScript which should be included
in the header of the Ajax response, so that the client can load up
those scripts and stylesheets upon completion of the Ajax request.
This could be coded quite cleanly, but for best results we'd want to
extend prototype.js with our own changes to their Ajax system, so that
every script had consistent support for this.
By the way, the ideal place for this line is _config.php in your custom module or in mysite, depending on your needs.

LeftAndMain::require_javascript('mysite/javascript/initGoogleMaps.js')
would work much better

Page-level execution of JavaScript when serving concatenated files

Scenario:
A web site with x number of pages is being served with a single, concatenated JavaScript file. Some of the individual JavaScript files pertain to a page, others to plugins/extensions etc.
When a page is served, the entire set of JavaScript is executed (as execution is performed when loaded). Unfortunately, only a sub-section of the JavaScript pertains directly to the page. The rest is relevant to other pages on the site, and may have potential side-effects on the current page if written poorly.
Question:
What is the best strategy to only execute JavaScript that relates directly to the page, while maintaining a single concatenated file?
Current solution that doesn't feel right:
JavaScript related to a specific page is wrapped in a "namespaced" init function for that page. Each page is rendered with an inline script calling the init function for that page. It works hunky-dory, but I would rather not have any inline scripts.
Does anyone have any clever suggestions? Should I just use an inline script and be done with it? I'm surprised this isn't more of an issue for most developers out there.

Just use an inline script. If it's one or two lines to initialize the JavaScript you need that's fine. It's actually a good design practice because then it allows re-use of your JavaScript across multiple pages.

The advantages of a single (or at least few) concatenated js files are clear (less connections in the page mean lower loading time, you can minify it all at once, ...).
We use such a solution, but: we allow different pages to get different set of concatenated files - though I'm sure there exists different patterns.
In our case we have split javascript files in a few groups by functionality; each page can specify which ones they need. The framework will then deliver the concatenated file with consistent naming and versioning, so that caching works very well on the browser level.
We use django and a home-baked solution - but that's just because we started already a few years ago, when only django-compress was available, and django compress isn't available any more. The django-pipeline successor seems good, but you can find alternatives on djangopackages/asset-managers.
On different frameworks of course you'll find some equivalent packages. Without a framework, this solution is probably unachievable ;-)
By the way, using these patterns you can also compress your js files (statically, or even dynamically if you have a good caching policy)

I don't think your solution is that bad although it is a good thing that you distrust inline scripts. But you have to find out on what page you are somehow so calling the appropriate init function on each page makes sense. You can also call the init function based on some other factors:
The page URL
The page title
A class set in the document body
A parameter appended to your script URL and parsed by the global document ready function.

I simply call a bunch of init functions when the document is ready. Each checks to see if it's needed on the page, if not, simply RETURN.

You could do something as simple as:
var locationPath = window.location.pathname;
var locationPage = locationPath.substring(locationPath.lastIndexOf('/') + 1);
switch(locationPage) {
case 'index.html':
// do stuff
break;
case 'contact.html':
// do stuff
break;
}

I'm really confused exactly why it doesn't feel right to call javascript from the page? There is a connection between the page and the javascript, and making that explicit should make your code easier to understand, debug, and more organized. I'm sure you could try and use some auto wiring convention but I don't think it really would help you solve the problem. Just call the name spaced function from your page and be done with it..

embedded javascript that is based on jQuery

I'm building a service that allows people to put a javascript code I gave them to their site.
The javascript code is based on jQuery.
My question is how to do this to be safe and optimized, cause I don't want to break certain users website.
The thing I'm looking for so far( you can update if you think I need to face other problems):
what happens when the user already has jquery loaded on their page? should I load my jquery library using different namespace or should I use his jquery library.
in case I can use his jquery library, I think I'll need to check to see if the versions corespond, but again is this safe?
in case I want to use his jquery library, how do I check if he has jquery loaded and if he has the right version
this is related to 3. what happen if he changes his jquery library that doesn't correspond with the library I think it will be, leading to a bad result.
Looking for your answers.
Thanks

Don't depend on the page's jQuery or try to use it. This will just turn into a support nightmare. You can't even be sure that a version is accurate, as the target page can alter its version of jQuery.
The best approach is for your code to create and load an iFrame. This gives you complete control over the iFrame's jQuery, CSS, etc. With vastly reduced chances of conflict.
If the iFrame approach is not possible for some reason, Use noConflict to minimize the chance of conflicting jQuery versions.
Something like this:
<script type="text/javascript">
if ($ || jQuery) {
var PagesLibrary = $;
var PagesjQuery = jQuery;
</script>
<!-- load your jQuery -->
<script type="text/javascript" src="http://example.com/jquery-1.6.2.js"></script>
<script type="text/javascript">
var my_jQuery = $.noConflict (true);
if (PagesjQuery) {
$ = PagesLibrary;
jQuery = PagesjQuery;
}
</script>
Then instead of $('#selector').function();,
Use: my_jQuery('#selector').function();.

Without the context of actually what your injected code does, it's hard to say. If you're writing a general bit of functionality, you probably want to just implement it as a jQuery plugin, specify what version you target, and then leave it to your users to decide how to include it, etc.
However, it sounds more like you're writing a service of some kind. In that case, I recommend the following course:
Place all the code you depend on (jQuery, other libraries, your code, etc) in an anonymous function wrapper, and have the snippet you have people just inject a script tag pointing to your js file. This is most likely to give you reliable results. If you require special information, like an ID, have the snippet just before the injection code set those values in a global variable, or have extra code that runs just after the injection to call a function of yours with the data. Look at how Google Analytics accomplishes this for reference. Either way, you'll need to affect the global scope.
I know that may not be what you wanted to hear. You could always create an elaborate jQuery detection and injection scheme, but you'd run into exactly the problems you mention (like version collisions etc). The safe way to go is to combine all the code you require along with your own and provide it all as one file which only makes internal references.
Hope this helps!