talk@lists.collectionspace.org
WE HAVE SUNSET THIS LISTSERV - Join us at collectionspace@lyrasislists.org
View all threadsappcache shenanigans (or, how to get your ui changes to show up in 2.0)
In testing the 2.0 mini-build, I decided to make a change to index.html, thinking that would be a simple case. As it turns out, it took me down a bit of a rabbit hole, and I thought I'd share my findings. You'll need to know this information if you want to edit certain files in the ui layer for your tenant. These are less commonly edited files. If you're just editing cspace.css and things under html/pages, you won't run into this.
CollectionSpace 2.0 uses HTML5 offline web application caching (aka "application caching", the "app cache"). See http://www.w3.org/TR/html5/offline.html#offline. Some of the files that are cached are defined in a manifest file, which for cspace is cspace.appcache (in defaults). Currently, these files are in the manifest:
js/index.js
js/template.js
js/record.js
js/myCollectionSpace.js
js/findedit.js
js/createnew.js
js/advancedsearch.js
js/administration.js
css/index.css
css/template.css
css/record.css
css/myCollectionSpace.css
css/findedit.css
css/createnew.css
css/advancedsearch.css
css/administration.css
In addition, html files with a manifest attribute will go in the application cache. For example, index.html has the line:
<html manifest="../cspace.appcache">HTML files in the top level of the html directory will go into the application cache, because they all have the manifest attribute. HTML files in the pages directory won't. They're fragments that are pulled down by the browser in a separate request from the "main" part of the page. Since they don't have a manifest attribute (let alone an html tag), the browser won't put them in the app cache.
This means that if you want to edit any of the js or css files listed in the manifest, or any of the html files in the top level of the html directory, you'll have to deal with application caching when you want to see your changes. Here's what I've learned:
-
The app cache is distinct from the "regular" browser cache. Clearing your regular cache has no effect on the app cache. In Chrome, you have to select "Delete cookies and other site and plug-in data" in the Clear Browing Data dialog in order to clear the app cache. Since this does a lot of collateral damage, you may prefer to visit chrome://appcache-internals/, and remove individual caches from there. Firefox probably has something similar.
-
Shift+reload doesn't work to force reload of app cached files.
-
To tell a browser to reload cached files after you've made a change (without the user having to clear the cache manually), you have to change the manifest (defaults/cspace.appcache). This means you have to copy cspace.appcache into your tenant directory. It doesn't matter what you change in the file. One way would be to add a comment containing a version number and/or timestamp, and edit it whenever a cached file has been changed. So the top of the file would be something like:
CACHE MANIFEST
Version 1
After deploying this to your server, you still have to reload twice to get the changes to show (at least in Chrome) -- the first time, it sees the manifest changed, and downloads the files in the background. The second time, it pulls the updated files from the cache.
- For development, when you're actively working on a cached file, editing the manifest with every change/deploy is annoying. You may want to turn off application caching in your browser (for Chrome, use the command line switch --disable-application-cache). You'll still have to change the manifest before commiting to svn, so that other people's browsers will know to reload the cached pages.
Hope this helps someone!
Ray
Here's some more information about application caching (thanks Aron),
including how to clear the app cache in Firefox (at the bottom of the
page): https://developer.mozilla.org/en/Using_Application_Cache
I'm unsure why cspace is using application caching in addition to regular
http caching. Aron has created CSPACE-4758
[http://issues.collectionspace.org/browse/CSPACE-4758] regarding
documentation around caching, including application caching.
Thanks,
Ray
On Tue, 20 Dec 2011 16:39:57 -0800, Ray Lee rhlee@berkeley.edu wrote:
In testing the 2.0 mini-build, I decided to make a change to index.html,
thinking that would be a simple case. As it turns out, it took me down a
bit of a rabbit hole, and I thought I'd share my findings. You'll need
to
know this information if you want to edit certain files in the ui layer
for
your tenant. These are less commonly edited files. If you're just
editing
cspace.css and things under html/pages, you won't run into this.
CollectionSpace 2.0 uses HTML5 offline web application caching (aka
"application caching", the "app cache"). See
http://www.w3.org/TR/html5/offline.html#offline. Some of the files that
are
cached are defined in a manifest file, which for cspace is
cspace.appcache
(in defaults). Currently, these files are in the manifest:
js/index.js
js/template.js
js/record.js
js/myCollectionSpace.js
js/findedit.js
js/createnew.js
js/advancedsearch.js
js/administration.js
css/index.css
css/template.css
css/record.css
css/myCollectionSpace.css
css/findedit.css
css/createnew.css
css/advancedsearch.css
css/administration.css
In addition, html files with a manifest attribute will go in the
application cache. For example, index.html has the line:
HTML files in the top level of the html directory will go into the
application cache, because they all have the manifest attribute. HTML
files
in the pages directory won't. They're fragments that are pulled down by
the
browser in a separate request from the "main" part of the page. Since
they
don't have a manifest attribute (let alone an html tag), the browser
won't
put them in the app cache.
This means that if you want to edit any of the js or css files listed in
the manifest, or any of the html files in the top level of the html
directory, you'll have to deal with application caching when you want to
see your changes. Here's what I've learned:
- The app cache is distinct from the "regular" browser cache. Clearing
your regular cache has no effect on the app cache. In Chrome, you have
to
select "Delete cookies and other site and plug-in data" in the Clear
Browing Data dialog in order to clear the app cache. Since this does a
lot
of collateral damage, you may prefer to visit
chrome://appcache-internals/,
and remove individual caches from there. Firefox probably has something
similar.
-
Shift+reload doesn't work to force reload of app cached files.
-
To tell a browser to reload cached files after you've made a change
(without the user having to clear the cache manually), you have to
change
the manifest (defaults/cspace.appcache). This means you have to copy
cspace.appcache into your tenant directory. It doesn't matter what you
change in the file. One way would be to add a comment containing a
version
number and/or timestamp, and edit it whenever a cached file has been
changed. So the top of the file would be something like:
CACHE MANIFEST
Version 1
After deploying this to your server, you still have to reload twice to
get the changes to show (at least in Chrome) -- the first time, it sees
the
manifest changed, and downloads the files in the background. The second
time, it pulls the updated files from the cache.
- For development, when you're actively working on a cached file,
editing
the manifest with every change/deploy is annoying. You may want to turn
off
application caching in your browser (for Chrome, use the command line
switch --disable-application-cache). You'll still have to change the
manifest before commiting to svn, so that other people's browsers will
know
to reload the cached pages.
Hope this helps someone!
Ray
Talk mailing list
Talk@lists.collectionspace.org