Community
Participate
Working Groups
Orion HEAD 10/31 The webEditingPlugin is not working, which means clicking a .js file doesn't open the Orion editor like it should. Doing a Reload from the Plugins page gives this: > Uncaught ReferenceError: define is not defined webContentAssist.js:14 > Uncaught ReferenceError: define is not defined htmlGrammar.js:15 > Uncaught ReferenceError: orion is not defined webEditingPlugin.html:17
Felipe is this in someway related to your recent change removing that old definition of define??
Clients who use the editor code without requirejs must have a "define" property in the global object or else the "define || defineGlobal(" pattern will throw. This is probably also the cause of the non-requirejs unit test failures
(In reply to comment #2) > Clients who use the editor code without requirejs must have a "define" property > in the global object or else the "define || defineGlobal(" pattern will throw. > This is probably also the cause of the non-requirejs unit test failures Usually when a client does not use requirejs it needs to include <script src="../../orion/textview/global.js"></script> see minimaleditor.html for an example. how can I run the webEditingPlugin ?
BTW, the minimal editor works because of this hack <script> // temporary var __originalDefine = window.define; </script> <script> // temporary window.define = __originalDefine; </script> We think the a better hack is to replace 'define' to window.define. But all plugins will still need to include the global.js script. That said, maybe this is a naive question, but shouldn't plugins be using requirejs ?
Released a fix for the plugin: http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=6ebf638b6245d7397cc27e804512f1f502c97578
*** Bug 362569 has been marked as a duplicate of this bug. ***
Changing to blocker. I tried deploying a build but it had complete lack of editors because of this problem.
(In reply to comment #5) > Released a fix for the plugin: > http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=6ebf638b6245d7397cc27e804512f1f502c97578 This doesn't feel like the right fix to me. Are we saying all plugins must either use require.js or include textview/global.js? webEditingPlugin.html doesn't even really know anything about the editor. All this plugin is doing is contributing a couple of services (content assist, syntax highlighter). It doesn't really care who is using those services and having the dependency on the textview script doesn't look right.
(In reply to comment #8) > This doesn't feel like the right fix to me. Are we saying all plugins must > either use require.js or include textview/global.js? webEditingPlugin.html > doesn't even really know anything about the editor. All this plugin is doing is > contributing a couple of services (content assist, syntax highlighter). It > doesn't really care who is using those services and having the dependency on > the textview script doesn't look right. I agree this is a hack, but note the plugin already has a dependencies in the editor (webContentAssist.js and htmlGrammar.js).
(In reply to comment #9) > I agree this is a hack, but note the plugin already has a dependencies in the > editor (webContentAssist.js and htmlGrammar.js). I didn't notice those dependencies had been added. I still don't see why the dependency is there... webContentAssist is just listing a bunch of keywords. It doesn't refer to the editor anywhere in its implementation. Same for htmlGrammar.js. It is a purely declarative grammar definition - it doesn't care about who is using the grammar. Interestingly my example ruby editor plugin still works even though it didn't add these dependencies (https://github.com/jarthorn/orion.ruby).
(In reply to comment #10) > Interestingly my example ruby editor plugin still works even though it didn't > add these dependencies (https://github.com/jarthorn/orion.ruby). Yes: you can contribute to the services without doing any require/global.js stuff. WebEditingPlugin is only doing this hack because it wants to use the implementation of CSS content assist + HTML highlighting that are in the editor code. So we're not forcing a general dependency here. I'm going to close this since the fix in Comment 5 gets the editor working again. I'll open another bug about fixing the packaging of webEditingPlugin.
