How to include external Javascript in GWT offline application - javascript

I have a GWT (well, GXT) application that uses an external JavaScript library to add functionality to my app. My application must work offline, too, and herein lies my problem.
I am aware that adding files to the public folder will make them accessible by my GWT app, but this will not work in case of offline use. GWT compiles my app to make it available offline without problem, but it doesn't include the external JavaScript library.
So, whenever I work within the application and reach the point where said library is needed, the browser will attempt a GET request because the library hasn't been loaded yet and doesn't remain in the cache of the browser reliably.
Is there a way to add the library to my app so that it will be cached together with my GWT app? The library consists of several folders, JS files, images, CSS, etc. My only idea is to dynamically create an Appcache Manifest that dumps ALL files in the browser cache.. in which case I'm scared of breaking the GWT offline functionality.

Yes you can generate a manifest at compile time. Just use a linker that extends com.google.gwt.core.ext.linker.AbstractLinker.
See for example this example manifest linker
or see Writing a GWT Linker
or see this stackoverflow thread
I do that to include google fonts and to produce a manifest that will only include files for that specific language permutation.

Related

Find all loaded files in website to create ApplicationCache manifest

I'm trying to figure out a way to automatically generate an ApplicationCache manifest file from all the HTML,CSS,JavaScript and images files used by our website.
We need this because we need to support offline usage of the website. More precisely, offline usage of an ArcGIS API for JavaScript webapp.
We are not using service workers instead of the ApplicationCache because supporting iOS is a critical requirement and service workers are not supported at all on iOS, on any browser.
The idea is that I'll manually call a function after the site is fully loaded that will dynamically create the text to be used for the new manifest. Then manually copy/paste it in the manifest file. So it's something I would only do when something in the site changes and the manifest file needs to be updated.
This tool, ManifestR, is very close: http://westciv.com/tools/manifestR/
but has two issues with it:
1- It does not handle image file URLs found in CSS files properly. For instance if it finds url(../images/myimage.png) it will add the relative link ../images/myimage.png directly in the manifest file instead of adding the non-relative link like www.mysite.com/images/myimage.png.
2- It does not list any of the scripts loaded through dojo.require (AMD modules).
I'm thinking of using similar code to fix these issues and compile the list of files. I already see how to fix #1, but can't figure out how to fix #2.
So, using JavaScript, how can I find the list of all script URLs used by the website, not just those loaded trough tags (found in window.scripts object), but those loaded using AMD modules as well?
Basically I want to compile the same list that Chrome is showing me for the website in the Sources pane.
Ex:
I'm thinking that if this isn't available anywhere, maybe I could create a proxy function to dojo.require that keeps tracks of all files loaded through AMD.
But I wanted to ask here first, maybe I missed a tool of script that already does this? Or maybe my plan isn't good?
Thanks
I've never used ApplicationCache for an ArcGIS API for JavaScript app, but I would recommend that you first serve up a custom Dojo build of your application in order to bundle your code into one or more build layers. If you configure your Dojo build properly (no small feat) you should know the exact scripts that will be required.
Also, I'd suspect that once you figure out how to get the list of scripts, you may have special considerations in order to get the Dojo AMD loader to be able to use the cached files. See: dojo and the offline application cache
Good luck.

Liferay application adapter does not work with javascript files

I need to use application adapter to implement different functionality for different sites. If I set 'false' in liferay-hook.xml, and select appropriate adapter in liferay 'site settings' all modifications which are in jsp files are displayed but modifications in js files are not.
Any ideas how to use application adapter to customize js files per site?
Thanks a lot for your reply.
You can't. An application adapter changes the way the application server resolves JSPs - while JS files are directly requested from the browser.
As JS files are typically minified, with no notion of different files due to the site, you'll have to make your JS files aware of the different conditions in which they run - e.g. introduce conditional initialization in them or embed different JS files in your themes (or make the themes configurable to include different JS files)

Browser Caching of javascripts and css files in mvc project

I have to cache the static javscript and css files in my SPA(durandal+knockout) .
When i put debug='false' in my webconfig of the app , the app gives the 'jQuery not defined' and 'KO not defined' error . This is happening even when the bundles are having the jQuery and KO javascript libraries.
Any suggestions and solutions for this issue ??
What is the importance of specifically mentioning caching of static JavaScript and CSS and the debug='false'; You felt it was important enough to mention first but then didn't tell us what's so special about it and why we need to consider it. - We need more infomation if this is critical to the problem.
i.e.
What is special about the caching is it located somewhere other than you site?
Does you app do something different when in debug mode?
Why does debug='false' effect the bundles which are dependent ONLY on the URL you request?
My Guess
Does you app make different requests when in debug mode so that it can see the individual debug versions of the libraries rather than one large single line file?
Have the two libraries been included in the non debug version. I've often seen MVC projects use a partial view to load both the CSS and JavaScript
something like _Script.cshtml
#if (HttpContext.Current.IsDebuggingEnabled)
{
... All the debug ./ developer versions of files listed here individually
}
else
{
#Scripts.Render("~/bundles/jquery")
}
Also if your static content is 'cached' on a separate URL / Site / CDN and you used NuGet to install Knockout or other libraries then it entirely possible that the where installed in the be local /Scripts folder and not the other site.

What are those cache.js and compilation-mappings files

Recently I received a package with web page. I see inside (beside normal html and js files) there are some JS files. It looks like this:
4A3674A3247236B3C8294D2378462378.cache.js
FE728493278423748230C48234782347.cache.js
compilation-mappings.txt
Inside .js files I see Javascript which is obfuscated or minified. Inside compilation-mappings.txt the cache.js are referenced. Are these files generated by some kind of WEB IDE? Unfortunately I have no chance to get information how this wep page was developed.
That is a web project coded in Java and compiled to JS using the GWT project tools.
GWT compiler does a lot of the work you would have to do manually when coding JS by hand, and some other tasks which are almost impossible in a normal JS project: obfuscate, compress, death-code removal, different optimization per browser, renaming of the scripts, code splitting, etc.
What you have in your app is the result of this compilation:
First you should have a unique index.html file, because GWT is used to produce RIA (Rich Internet Applications) also known as SPI (Single Page Interface).
The unique html file should have a reference to a javascript file named application_name.nocache.js. Note the .nocache. part, meaning that the web server should set the appropriate headers, so as it is not cached by proxies nor browsers. This file is very small becaust it just have the code to identify the browser and ask for the next javascript file.
This first script knows which NNNN.cache.js have to load each browser. The NNNN prefix is a unique number which is generated when the app is compiled, and it is different for each browser. GWT supports 6 different browser platforms, so normally you would have 6 files like this. Note the .cache. part of the name, meaning that this files could be cached for ever. They are large files because have all the code of your application.
So the normal workflow of your app is that the browser ask for the index.html file which can be cached. This file has the script tag to get the small start script applicaton.nocache.js which should be always requested to the server. It has just the code for loading the most recent permutation for your browser NNNN.cache.js which will be downloaded cached in your browser for ever.
You have more info about this stuff here
The goals of this naming convention is that the next time the user goes to the app, it will be in cache the index.html and NNNN.cache.js files, asking only for the application.nocache.js which is really small. It guarantees that the user loads always the most recent version of the app, that the browser will download just once the code of your app, that proxies or cache devices do not break your app when releasing a new version, etc.
Said that, it is almost impossible to figure out what the code does inspecting the javascript stuff because of the big obfuscation. You need the original .java files to understand the code or make modifications.
I can't say for sure, but often a string will be attached to the name of a javascript file so that when a new version is deployed clients will not use a cached version of the old one.
(ie, if you have myScript.js and change it, the browser will say "I already have myScript.js, Idon't need it. If it goes from being myScript1234.js to myScript1235.js the browser will go fetch it)
It is possible the framework in use generated those files as part of it's scheme to handle client side cache issues. Though without knowing more details of what framework they used, there's no way of knowing for sure.

Loading local files via jQuery (part 2)

Ok, here we discussed the essence of the problem: in some browsers like Chrome and Opera HttpRequests to local files is turned off by default.
Now the question is: how to build such HTML+javascript viewer of HTML documents, that:
would run locally on any (or most of) browser(s) without additional tuning;
would not use frames;
would have an ability to work with many different files(5-10k);
It can't be done in straight HTML/Javascript if you want to load files via Javascript using AJAX requests. There are good security reasons to not allow local files script access to other files on the local system (see my answer here for more details), so most browsers will not allow this without special user configuration.
So your options are:
Don't load files with Javascript, use frames or another mechanism. If, as you state in the other question, you're shipping all this on CD, you might want to consider using some sort of build system that allows you to create static files using templates and either a database or flat-file content - Jekyll is one option I know of.
Ship an executable along with the files that can either run a local webserver or run HTML files in an application context. I think Appcelerator Titanium might fit the bill.

Categories

Resources