Community
Participate
Working Groups
We now have IP approval so can begin looking at moving to Dojo 1.6. This should help us with some aspects of IE9/FF4 support but also allows us to try out the CommonJS AMD style of handling dependencies.
I've checked the dojo 1.6 version into Orbit now. One of the changes vs. 1.5 is that the "source" uses CommonJS AMD syntax instead of dojo.require/dojo.provide. The idea is that you run a build step which by default in 1.6 will replace the CommonJS AMD "define" calls with dojo.require/dojo.provide calls. More details here -- http://dojotoolkit.org/reference-guide/releasenotes/1.6.html -- The problem is that at dev time we're not using a real build and in addition reference dojo.js.uncompressed.js which is built and in particular does not provide the CommonJS AMD "define" function as the build process removed it. In the short term I have added a definition for "define" to the dojo.js.compressed.js file so we can use Dojo 1.6 immediately. We need a better build/dev story for this for M7 but... To try out dojo 1.6 just checkout the v1_6_0 branch and that should do it. After we sort out a better story for our build/dev experience and have made sure everything still works we can really move to 1.6 and close this bug.
I have rebuilt the org.eclipse.orion.dojo layer based on dojo 1.6 and pushed it to a dojo_160 branch.
Andrew is going to kick off a build based on this branch. I'll try running the latest client against it and report back....
If you're trying this in your workspace with the existing org.eclipse.orion.dojo project you will need to prevent use of the orion.js.uncompress.js file. Probably the simplest way to do this is to make a copy and then delete the contents of the file.
The immediate problem we run into is in our eWebBorderContainer.js: Uncaught TypeError: Cannot read property 'style' of undefined chrome-devtools://devtools/js/widgets/eWebBorderContainer.js:139 - It looks like instead if we want this functionality we will have to use container.getChildren() and iterate to find "left" or else rethink this widget
Here is the test build: http://download.eclipse.org/e4/orion/drops/I201104261350/index.html If any code changes are being made to adopt 1.6, we should probably do them on the dojo_160 branch until we are ready to make the switch for real.
Having now tried more I think this is too risky for M7 however we should try to eliminate any problems so we can make the switch early in M8. I'll continue working through and listing any issues I come across here, creating new bugs etc. If anyone else tries this out they should do the same as I would like to use this bug as a parent.
(In reply to comment #5) > The immediate problem we run into is in our eWebBorderContainer.js: > > Uncaught TypeError: Cannot read property 'style' of undefined > chrome-devtools://devtools/js/widgets/eWebBorderContainer.js:139 > > - > It looks like instead if we want this functionality we will have to use > container.getChildren() and iterate to find "left" or else rethink this widget I can look at this. There used to be some additional state kept in this widget but when I generalized it for use in navigator, I cleaned out some cruft but used some private state. I'll try to come up with a nice fix that works on 1.5 and 1.6, it was wrong to rely on internals.
I have built org.eclipse.orion.dojo for 1.6.1 and pushed it to a dojo_161 branch. I will be producing a test build shortly
(In reply to comment #9) > I have built org.eclipse.orion.dojo for 1.6.1 and pushed it to a dojo_161 > branch. > > I will be producing a test build shortly Test build for this is currently available at http://build.eclipse.org/eclipse/e4/orion/I201105091450/I20110509-1450/
Looks good now. Susan found a bug with the toggle splitter in FF4 that needs fixing -- bug 345206 -- but otherwise looks ok.
