Hi Laurent. On Thu, Mar 8, 2012 at 6:13 AM, Laurent Malvert <lmalv...@idbs.com> wrote: > On Thursday, February 2, 2012 4:47:34 AM UTC, Henrik Bengtsson wrote: >> [...] > >> When time permits, I'll also update ArrayExplorer (which still only >> works in Firefox 3.x). > > Hello Henrik, > > > I am unfamiliar with the project as a whole, but I was asked to find a way > to make ArrayExplorer work earlier this week. Unfortunately I only noticed > today while checking if there would be an earlier version that this was a > known issue. I'm sure that Keith's post could have helped otherwise.
Thanks for doing this and I guess also thanks to the person(s) who asked you to look into this. I think might we might have done parallel work here. From the efforts of getting ChromosomeExplorer to work (thxs again to Keith Ching), I've got a rough update of ArrayExplorer working, and two days ago I had another shot at it. It now appears to work across several modern browsers. Online examples: ArrayExplorer v3.4: http://aroma-project.org/data/reports/GSE8605/raw/ArrayExplorer.html http://aroma-project.org/data/reports/GSE8605/RMA/ArrayExplorer.html ChromosomeExplorer v3.4: http://aroma-project.org/data/reports/Affymetrix_2011-CytoScanHD/ACC,ra,-XY,BPN,-XY,AVG,FLN,-XY/ChromosomeExplorer.html Note that ArrayExplorer downloads the "full resolution" spatial image before displaying it, so there may be a delay before anything appears. The possibility to generate these versions (or some iterations of them) will be available in the next release of the Aroma framework (aroma.affymetrix v2.5.0 et al.). Unfortunately it is not possible pre-release it, because there are too many convoluted updates across many packages. I will soon start submitted these updates to CRAN one by one, to make sure things are not breaking. The good news are that everything works well in the 24-hour system tests used for validating aroma, so hopefully it shouldn't take too long. More comments below... > > We found multiple issues in ArrayExplorer's loading, so maybe I can help a > bit. > I'll try to get a closer look at your whole project when time permits to > submit a proper patch, but in between maybe I can shed some light on what's > happening and what we did to fix it (which is NOT the right way, but that > was a quick-n-dirty solution for us for an internal product). > > > ## Issues > > - main.js instantiates ArrayExplorer without verifying that is has been > loaded first (for some reason, the FF versions where it works are probably > not downloading JS files in parallel, which allowed them to be loaded and > executed in the correct order). This needs to be deferred to the onLoad > event. Yes, asynchronously loading of Javascripts was the number one issue with ChromosomeExplorer and ArrayExplorer. I didn't know that it could be that earlier versions of Firefox didn't load in parellel, but it sounds plausible. I must admit that my knowledge of Javascript/DOM/... of browsers is rather patchy from ad hoc trial errors. Hmm... I never thought of relying on onLoad() as the gathering/launch point. My solution was to use require.js [http://requirejs.org/] to load all scripts and the when done launch the main function... indeed inside onLoad(). I'll probably leave it at that for now, because I have litte time to do another round of design/code/validation. However, if possible, it may be worthwhile to drop unnecessary dependencies in the Explorers. > - includeDom() calls require missing files: > - "extras.js" (wasn't part of the version I had) > - "../ArrayExplorer.onLoad.js" (which was already included a few lines > before with includeDom("ArrayExplorer.onLoad.js") That was intentional; it was basically a static way of providing backward compatibility with earlier versions of Explorers. The code didn't expect all of them to exists, but at least one of them. I guess there were some ugly error message generated. > - some other deferred loading issues, as the includeDom calls attempt to > access ArrayExplorer > > ## Solution(s) > > I worked that out by writing out the following, which, *I stress it again*, > is *NOT the right way*. But in the situation I had we couldn't directly edit > the file so it had to be patched by a script reading the file's stream on > the fly, and this was sufficient to get things going (there's still at one > other JS error left, but it didn't block us anymore and I didn't have more > time to allocate for this support call). Apologies then for the ugliness: > > The dirty trick was essentially to rewrite this: > > {code} > var explorer = new ArrayExplorer(); > > window.onresize = function() { > explorer.update(); > } > > includeDom("../ArrayExplorer.onLoad.js"); > includeDom("ArrayExplorer.onChipType.js"); > includeDom("ArrayExplorer.onLoad.js"); > includeDom("extras.js"); > > function onLoad() { > explorer.start(); > webcutsOptions['numberLinks'] = false; > } > {code} > > To become this: > > {code} > var explorer = {}; > > window.onresize = function() { > explorer.update(); > } > > > includeDom("ArrayExplorer.onChipType.js"); > includeDom("ArrayExplorer.onLoad.js"); > > > function onLoad() { > // InforSense Patch > var _onLoad = explorer.onLoad; > var _onChipType = explorer.onChipType; > > explorer = new ArrayExplorer(); > explorer.onLoad = _onLoad; > explorer.onChipType = _onChipType; > explorer.start(); > // -- InforSense Patch > webcutsOptions['numberLinks'] = false; > } > {code} > > > If you must know, was very gorily patched from within our product's > scripting platform with this in Groovy (I did warn you of the ugliness, > right?): I like the "ugliness" ;) > > {code} > if (input.indexOf("InforSense Patch") == -1) { // prevent a double re-patch > input = input.replace( > "var explorer = new ArrayExplorer();", // replace premature > instantiation... > "var explorer = {};"); // ... w/ dummy object to allow > dynamic loaders to hook > > input = input.replace( > 'includeDom("../ArrayExplorer.onLoad.js");', // removing (and apparently > duplicated) import > ''); > input = input.replace( > 'includeDom("extras.js");', // removing wrong import > (consequences?) > ''); > > input = input.replace( > // replace this > "explorer.start();", > > // with all this (in the onLoad() handler hooked on <body>) > "// InforSense Patch --\n" + > " var _onLoad = explorer.onLoad;\n" + // backup onLoad > handler > " var _onChipType = explorer.onChipType;\n" + // backup onChipType > handler > "\n" + > " explorer = new ArrayExplorer();\n" + // instantiate once > " explorer.onLoad = _onLoad;\n" + // restore onLoad > handler > " explorer.onChipType = _onChipType;\n" + // restore onChipType > handler > " explorer.start();\n" + // put back starter > " // -- InforSense Patch" > ); > logger.info("ArrayExplorer hopefully successfully patched."); > } else { > logger.info("Skipping. ArrayExplorer was already patched."); > } > {code} Are the logger.info() functions from Log4JS? Do you know if it is safe to use across browser platforms? Right now I do a lot of tedious adding/dropping of alert() as I try things out. > > > Also, note that ArrayExplorer was perfectly working if not served from a > remote server, but access directly via a filesystem URI. > Apparently, in that particular case, FF doesn't complain about missing files > and resources were loaded in the right order. > > Another possible solution to solve the issue, if some are interested, is to > configure your browser to disable parallel resource loading. > This is done in Firefox via an internal property, and in IE via a registry > key. > > > Hope this helps. Sorry for not sending a proper patch, I hope I'll get a > chance to get to it. Thanks - I really appreciate it. It is useful feedback and I learn from your troubleshooting/experiences too. /Henrik > > -- > Laurent Malvert | Senior Software Developer | IDBS > ******** | www.idbs.com > > Powering Science for a Better Future > > -- > When reporting problems on aroma.affymetrix, make sure 1) to run the latest > version of the package, 2) to report the output of sessionInfo() and > traceback(), and 3) to post a complete code example. > > > You received this message because you are subscribed to the Google Groups > "aroma.affymetrix" group with website http://www.aroma-project.org/. > To post to this group, send email to aroma-affymetrix@googlegroups.com > To unsubscribe and other options, go to http://www.aroma-project.org/forum/ -- When reporting problems on aroma.affymetrix, make sure 1) to run the latest version of the package, 2) to report the output of sessionInfo() and traceback(), and 3) to post a complete code example. You received this message because you are subscribed to the Google Groups "aroma.affymetrix" group with website http://www.aroma-project.org/. To post to this group, send email to aroma-affymetrix@googlegroups.com To unsubscribe and other options, go to http://www.aroma-project.org/forum/
