Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [orion-dev] Custom Types/Globals in CodeEditWidget

https://bugs.eclipse.org/bugs/show_bug.cgi?id=493379



From:        Sebastian Pahnke <pahnke.sebastian@xxxxxxxxx>
To:        Orion developer discussions <orion-dev@xxxxxxxxxxx>
Date:        05/10/2016 11:15 AM
Subject:        Re: [orion-dev] Custom Types/Globals in CodeEditWidget
Sent by:        orion-dev-bounces@xxxxxxxxxxx




Hi,

what if I could tell the „in-memory“ file system the contents of such a file instead of the location. For instance, when I create the code edit widget on my page I would write:

codeEdit.setFileContents('.eslintrc', <content>) or
codeEdit.setFileContents('.tern-project', <content>)

Then, whenever the file system is queried for such a file, it just returns these contents, instead of resolving a physical file. Would that be a possible solution? I don’t know the Orion architecture very well, so please tell me if this is nonsense :) I at least think it would be a practical workaround for the code edit widget, since you have to create an instance anyway before you can use it.

Regards,
Sebastian


Am 06.05.2016 um 16:49 schrieb Libing Wang <Libing_Wang@xxxxxxxxxx>:

Curtis:
codeEdit consumes an "in-memory" file system that is barely a place holder to workaround the Orion inputManager. This file system is registered as the default file system, taking care of file read, write, etc.
I think the real challenge here is that, for example, the "in-memory" file system has no idea on where the imported files are. So unless end user implements a real file system and pass it as a user plugin, it is hard to support this.


Libing





From:        
Curtis Windatt/Ottawa/IBM
To:        
Orion developer discussions <orion-dev@xxxxxxxxxxx>
Cc:        
Libing Wang/Ottawa/IBM@IBMCA
Date:        
05/05/2016 03:10 PM
Subject:        
Re: [orion-dev] Custom Types/Globals in CodeEditWidget



Yes a .eslintrc file could be used to set the environment.  We were just demo'ing this feature this afternoon.  The problem is the same as the .definitions folder.  codeEditWidget has no project, so the tooling can't search for those files.


Libing, do you have any ideas on how we could workaround this?


Curtis





From:        
Sebastian Pahnke <pahnke.sebastian@xxxxxxxxx>
To:        
Orion developer discussions <orion-dev@xxxxxxxxxxx>
Date:        
05/05/2016 01:00 PM
Subject:        
Re: [orion-dev] Custom Types/Globals in CodeEditWidget
Sent by:        
orion-dev-bounces@xxxxxxxxxxx




Hi Curtis,

as I have seen you have integrated .eslintrc support for the Orion IDE. I don’t know how hard it is, but if the codeEditWidget API could provide a function to feed in an .eslintrc file, then I could just set the required eslint-env directive once and accomplish 2) without hacking the built _javascript_Plugin file. Just an idea :)

But as for now, the solution works fine and I thank you for your help.

Regards,
Sebastian


Am 05.05.2016 um 15:26 schrieb Curtis Windatt <
Curtis_Windatt@xxxxxxxxxx>:

That's great that you were able to inject a new tern plugin into the build ternWorkerCore.

No there is no way to modify the default eslint environments.  To help users with this we have additional eslint rules that will mark the code warning about no environment directive set.  That rule has a quick fix to set the missing eslint-env entry in your file.  I'm not sure how difficult hooking into these quick fixes would be (and whether having to have an eslint-nev directive is reasonable to you).  Maybe in the future our ESLint implementation would look at everything Tern is aware of and ignore the eslint-env, but that isn't our current focus.

Curtis




From:        
Sebastian Pahnke <pahnke.sebastian@xxxxxxxxx>
To:        
Orion developer discussions <orion-dev@xxxxxxxxxxx>
Date:        
05/04/2016 02:28 PM
Subject:        
Re: [orion-dev] Custom Types/Globals in CodeEditWidget
Sent by:        
orion-dev-bounces@xxxxxxxxxxx




Hi,

I just wrote a simple test Tern plugin replicating my use case (see below).

1) If I hack this into the dependency list of ternDefaults in the built ternWorkerCore file and add the plugin name to the required plugins, my types are loaded and if I specify /* eslint-env mytypes */ in the editor I can see the code completion for them.

2) If I hack  „mytypes: true“ into the list of standard environments in TernAssist.computeContentAssist in the built _javascript_Plugin file, I can omit the eslint-env directive and use code completion for my types right away.

Using this approach I can completely get rid of the extension of the builtin object in eslint/conf/environments, which is nice. Can I somehow achieve 2) from outside the built files?

@Libing: I know the user plugins and already make use of them for other use cases. But they don’t help me in injecting a custom Tern definition file and enable code completion. For that I just want to use the existing framework.

Example Tern plugin:
define([
"tern/lib/tern",
], function(tern) {

  tern.registerPlugin("mytypes", function(server, options) {
server.addDefs(defs);
});

  var defs = {
      "!name": "mytypes",
      "Foo": {
          "!type": "fn()",
          "create": {
            "!type": "fn(name: string) -> +Foo",
            "!doc": "Returns a new Foo object."
          },
          "prototype": {
              "name": {
                "!type": "string",
                "!doc": "The name of the Foo."
              }
          }
      }
  };
});

Regards,
Sebastian


Am 04.05.2016 um 19:50 schrieb Libing Wang <
Libing_Wang@xxxxxxxxxx>:

Just a reminder that you can pass any user plugins if you are not aware of that...

https://wiki.eclipse.org/Orion/How_Tos/Code_Edit#Passing_user_plugins

-Libing




From:        
Sebastian Pahnke <pahnke.sebastian@xxxxxxxxx>
To:        
Orion developer discussions <orion-dev@xxxxxxxxxxx>
Date:        
05/04/2016 12:46 PM
Subject:        
Re: [orion-dev] Custom Types/Globals in CodeEditWidget
Sent by:        
orion-dev-bounces@xxxxxxxxxxx




It’s OK :)
I will look into writing a Tern plugin and see if that at least helps in reducing the hacking and the update overhead.

Thanks and regards,
Sebastian


Am 04.05.2016 um 18:29 schrieb Curtis Windatt <
Curtis_Windatt@xxxxxxxxxx>:

Right, this being in the code edit widget is going to be a problem.  Loading .definition folders, using .tern-project file, etc. are all based around having a project.  And CodeEditWidget doesn't have a project...

So assuming you are stuck hacking in definitions, I would still recommend adding them as a Tern plugin, then modifying TernDefaults to load that plugin.  However, I doubt you could do that in the built/minified code.  We don't have a workflow to load all of the plugins in a folder, we load each one in TernDefaults.

This is not very helpful for you :(

Curtis




From:        
Sebastian Pahnke <pahnke.sebastian@xxxxxxxxx>
To:        
Orion developer discussions <orion-dev@xxxxxxxxxxx>
Date:        
05/04/2016 11:04 AM
Subject:        
Re: [orion-dev] Custom Types/Globals in CodeEditWidget
Sent by:        
orion-dev-bounces@xxxxxxxxxxx




Hi,

currently it is rather a „hack in“ than a „hook in“ or plugin, since I have to patch the built ternWorkerCore and _javascript_Plugin files, because I know of no other way :)

1) Can I use that with the CodeEditWidget and if yes, where do I have to put the .definition folder?

2) I don’t really setup „custom completions“, I just add my (dynamic) Tern definition file into the built ternWorkerCore file (in the ternDefaults definition, like ecma5, ecma6, chai). So nothing too complicated.
Let’s say I succeed in adding my type definitions via 1) (see my example file from the last email), then I could activate the code completion for my types simply by adding /* eslint-env mydefinition */, right? So the only feature missing for my needs would be „Turning of filtering based on eslint-env“, as you said. Do I understand that correctly?

3) Again, I don’t setup a custom ESLint validation, I just patch the ESLint globals (see eslint/conf/environments) in the built ternWorkerCore file so that my custom types appear as builtin types, just as String or Date are. Otherwise a new MyType1() would give me red squiggles.

I hope that makes it clearer.

Regards
Sebastian


Am 04.05.2016 um 16:03 schrieb Curtis Windatt <
Curtis_Windatt@xxxxxxxxxx>:

Your plugin adds 1) Type definitions for Tern  2) Custom completions and 3) ESLint validation?  

1) We have limited support already for adding type definitions.  See Bug 484833
https://bugs.eclipse.org/bugs/show_bug.cgi?id=484833

2) Custom completions would require a new Tern plugin that contributes on the 'completions' request.  We would like to support third party Tern plugins, though at the moment we are focused on fetching type definitions for your code (creating or finding an index for some node module you are using).  I was pretty sure we had a bug for this, but I don't see one, so feel free to create one.  Turning off the filtering based on eslint-env will be one step towards this.  The only thing holding us back from that change is that projects without a .tern-project entry would get all of our templates showing up in content assist all the time.

3) We haven't set up a way to contribute to our ESLint setup so I would be interested in how you are hooking in.  Adding new rules shouldn't be difficult but when setting up the configuration for ESLint we are doing lookups in Orion's preference service as well as looking at eslintrc files.

Curtis




From:        
Sebastian Pahnke <pahnke.sebastian@xxxxxxxxx>
To:        
Orion developer discussions <orion-dev@xxxxxxxxxxx>
Date:        
05/04/2016 02:55 AM
Subject:        
[orion-dev] Custom Types/Globals in CodeEditWidget
Sent by:        
orion-dev-bounces@xxxxxxxxxxx




Hi,

to use the CodeEditWidget and its completion/validation features with my own custom types, I currently have to do the following steps (which currently work fine for me):

1. In ternWorkerCore.js search for the ternDefaults definition and add a link to my
ASP.NETHTTP request handler (e.g. TypeHandler.ashx?return=types) to the dependencies list => this loads the code completion definitions for Tern

2. In ternWorkerCore.js search for eslint/conf/environments and add a link to my request handler (e.g. TypeHandler.ashx?return=globals) which extends the builtin globals by my types => ESLint knows my types WITHOUT having to specify a eslint-env directive

3. In _javascript_Plugin.js search for ecma5 in the computeContentAssist function and add the name of my type definition file (e.g. mydefinition: true)

The mentioned request handler dynamically creates the Tern definitions / ESLint globals for the custom types (see below for example outputs), because they can possibly change due to a plugin concept. Therefore a static definition file is not sufficient.

But this procedure is tedious and error prone especially when I update the widget, since the mentioned files are minified by default(!). To figure out the steps above I actually created a custom build definition which omits the minification step.

With all the new possibilities due to .tern-project files, is there an easier way to accomplish this? Ideally I would like to write some kind of plugin file where I setup all I need and then just feed it to the CodeEditWidget by a function/during the create step. The important points for me are:
1. A dynamic HTTP request handler has to work, a static definition file is not sufficient
2. The types should behave like builtins without the need to specify a eslint-env directive in every script

TypeHandler.ashx?return=types returns a Tern definition file like this:
define([], function () {
           return {
                            "!name": "mydefinition",
                           
                            MyType1: {
                                             ...
                            }
           };
});

TypeHandler.ashx?return=globals returns ESLint globals like this (extending the predefined builtins!):
define(["eslint/conf/globals"], function (globals) {
           globals.builtin.MyType1 = false;
           ...
           return { builtin: globals.builtin };
});

Thanks and regards,
Sebastian

_______________________________________________
orion-dev mailing list

orion-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

https://dev.eclipse.org/mailman/listinfo/orion-dev




_______________________________________________
orion-dev mailing list

orion-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

https://dev.eclipse.org/mailman/listinfo/orion-dev
_______________________________________________
orion-dev mailing list

orion-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

https://dev.eclipse.org/mailman/listinfo/orion-dev


_______________________________________________
orion-dev mailing list

orion-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

https://dev.eclipse.org/mailman/listinfo/orion-dev
_______________________________________________
orion-dev mailing list

orion-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

https://dev.eclipse.org/mailman/listinfo/orion-dev

_______________________________________________
orion-dev mailing list

orion-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

https://dev.eclipse.org/mailman/listinfo/orion-dev
_______________________________________________
orion-dev mailing list

orion-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

https://dev.eclipse.org/mailman/listinfo/orion-dev


_______________________________________________
orion-dev mailing list

orion-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

https://dev.eclipse.org/mailman/listinfo/orion-dev
_______________________________________________
orion-dev mailing list

orion-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

https://dev.eclipse.org/mailman/listinfo/orion-dev


_______________________________________________
orion-dev mailing list

orion-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/orion-dev
_______________________________________________
orion-dev mailing list
orion-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/orion-dev



Back to the top