Community
Participate
Working Groups
Build ID: I20090202-1535 Steps To Reproduce: 1. Install PDT. 2. Install DLTK Javascript 3. Create PDT project 4. inject Javascript nature to the .project file of the created PDT project, like this: <natures> <nature>org.eclipse.php.core.PHPNature</nature> <nature>org.eclipse.dltk.javascript.core.nature</nature> </natures> 5. create a couple of javascript files in the project, fill it with sample functions 6. use code completion for one of these files. Expected result: code completion proposals contain functions defined in all the javascript files in the project. What actually happens: only local proposals (specific to the file where code completion is called) are in the list. More information: I looked deeper in DLTK code and it appears that in a lot of places it assumes that one project matches one nature and one language. In the end it all comes to methods such as org.eclipse.dltk.internal.core.util.Util#isValidSourceModule(...), which validate the resource to match the project's toolkit, which is usually the first one matching the first one of script natures of a project (see PriorityDLTKExtensionManager#findScriptNature(IProject) method). So the problem is, it appears that currently DLTK does not support more than one language per project, which is a common situation in web projects. Is there some known workaround for this problem?
> I looked deeper in DLTK code and it appears that in a lot of places it assumes > that one project matches one nature and one language. ... you answered the question yourself. DLTK support only one language per project by design, so the only one "workaround" exists is to change DLTK design.
Andrey, Okay, so this behaviour is as intended by design. But a common practice for lot of script languages out there is to use them for web development, which inevitably brings us to Javascript integrated into the other code in one way or another. Correct me if I'm wrong but this looks like a major use case to support for DLTK. I agree that this is not a bug as it does not violate the expected behaviour, but what would you say of this as an enhancement request?
Re-opening bug. Let's discuss how DLTK should be re-designed here.
Hi all, Here are a couple of ideas that might suit multiple nature projects and you might consider in the decisions you make: 1. support for adding and removing script natures/facets in DLTKCore. Such functionality should also be automatically triggered by DLTK on certain events. For example, when a file is opened with an editor that belongs to a script nature plugin. This nature should be added to the file's project (of course the user must be prompted to do this) 2. providing an extension for nature specfic Script Explorers (a minor thing: let the extension provide the name of the view: PHP explorer, Query Explorer, etc). This way plugins like PHP would not have to implement their own script explorer. This can also avoid complicating things in the default Script Explorer (lik for example interpreter tree viewer nore, decorators, etc.). As more ideas might come, I will dump them in this discussion. Thanks! Regards, Gabriel
I've created a thread into Eclipse`s Forum.
https://www.eclipse.org/forums/index.php/m/1670021/#msg_1670021
I have idea how-to fix this. Of course it introduce lot of compatibility problems (force us to use 6.0.0 version) but should be relatively simple. 1. Create ModelManager API interfaces 2. Keep ModelManager per LanguageToolkit and make it replaceable for toolkit. 3. In future move default model implementation into separate plugin and make it optional. This solve lots of potential problems: 1. Allow ISourceModule for same IResource (for example JavaScript and PHP) 2. Prevent mixing ISourceModule in same project between LangugeToolkits 3. Allow models pluggable (for example possibility use Handly as a replacement) What You think? I want invest my time to work on this but want to make sure you agree with that.
