This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 204187 - Code completion only inside a project. Toolkits impossibile usage.
Summary: Code completion only inside a project. Toolkits impossibile usage.
Status: NEW
Alias: None
Product: javascript
Classification: Unclassified
Component: Editor (show other bugs)
Version: 7.0.1
Hardware: All All
: P1 normal with 8 votes (vote)
Assignee: Petr Pisl
URL:
Keywords:
Depends on: 165124
Blocks:
  Show dependency tree
 
Reported: 2011-10-25 08:24 UTC by riksoft
Modified: 2014-02-14 22:17 UTC (History)
3 users (show)

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description riksoft 2011-10-25 08:24:48 UTC
+++ This bug was initially created as a clone of Bug #165124 +++

NetBeans has good "Import" feature in java file and "Include" file in php file. 
Why not extend it to support javascript .

The worst is that Netbeans 7 does a good job with most toolkits, like Dojo, BUT ONLY IF they are put in the project dir.
I didn't find any way to put Dojo (and the others toolkits) in a root dir, so they can be referenced by many projects without duplicating everything in every project dir.

THAT IS A MUST not only for space problems, but also for maintainability: just imagine I have to do a change in 1 line and I must replicate in 20 projects! :-(

So, a simple way to cope with this HUGE design bug, is the same as Eclipse: an option to specify the paths to dirs, using that option to extend the dirs Netbeans scans to create code completions rules.

I think an expert developer of the Netbeans team can do that in 20 minutes.

Without this option I can't use Netbeans for Javascript projects.
See Also
http://forums.netbeans.org/topic43936.html

PS: I'm not able to start a new bug from scratch so I used the most compatibile to start a new one.
Comment 1 Petr Pisl 2011-10-25 08:33:15 UTC
I absolutely agree with you. It would be sufficient to implement for JavaScript support something like global include path for PHP?
Comment 2 Petr Pisl 2011-10-25 13:22:11 UTC
If you put the folder with js files as one item of Include Path (project or global), it should work. Did you try it?
Comment 3 riksoft 2011-10-25 14:08:35 UTC
I tried last sunday but it works only for php not js.
I think there is an implicit filter such as *.php and that solution doesn't work for js.
Comment 4 riksoft 2011-10-30 13:28:59 UTC
I've done a workaround for linux: making a soft link in the project have the same effect as putting the real dir inside the project.

So, having prj1 with /dojo and prj2 with a php project, adding a link in prj2 such as ln -fs ../prj1/dojo, solev the problem.

The same trick doesn't apply to windows: netbeans ignores windows links.
Comment 5 schkovich 2011-11-02 13:12:39 UTC
Most commonly I would use vendor branch [1]. Therefore I see no advantage in proposed change. Actually proposal is quite close to bad practice. I do understand that in real life one cannot always use vendor branches but nevertheless the NetBeans IDE should not encourage such practice. 

Further on, I don't see why is this bug marked as P1. [2] At best priority can be P3. There are way much more important issues then this one.

[1] http://svnbook.red-bean.com/en/1.1/ch07s05.html
[2] http://wiki.netbeans.org/BugPriorityGuidelines
Comment 6 riksoft 2011-11-02 15:28:07 UTC
>Actually proposal is quite close to bad practice.
Let people decide on it. This is the first time I face a product that force to have library INSIDE the project itself.

Vendor branch can be a "solution" for some cases, but not for all cases and anyway is very bad supported in Netbeans because is certainly not a good choice to degenerate, in unnatural manner, the Netbeans Project using it as a multiproject container.

Netbeans is clearly designed to have 1 folder for 1 project (that's shown by the option that relate 1 project to another).

So, the right way (used also from Eclipse, Visual Studio, and any other IDE of the universe) is

/dojoroot
/Proj1
/Proj2
/Proj3

not

/ProjVendor
/ProjVendor/dojoroot
/ProjVendor/SubProj1
/ProjVendor/SubProj2
/ProjVendor/SubProj3

The 2nd way I suppose will also introduce a great overhead in the IDE, in that Netbeans scans everything, and also show everything in the code completion, even what I don't have to see.

Just imagine 10 projects: 2 use dojo, 2 jquery, 2 dojo + jquery, 2 YUI + jquery:
With vendor branch I should have

/ProjVendor1
/ProjVendor1/dojoroot
/ProjVendor1/SubProj1
/ProjVendor1/SubProj2


/ProjVendor2
/ProjVendor2/jquery
/ProjVendor2/SubProj2
/ProjVendor2/SubProj3

/ProjVendor3
/ProjVendor3/jquery
/ProjVendor3/dojoroot
/ProjVendor3/SubProj4
/ProjVendor3/SubProj5

/ProjVendor4
/ProjVendor4/jquery
/ProjVendor4/YUI
/ProjVendor4/SubProj6
/ProjVendor4/SubProj7

having to maintain 2 dojoroot and 3 jquery even if are all the same versions.
Then, when SubProj1 have to use jQuery, I have to move it under ProjVendor2.

The same under Eclipse (or even Netbeans if used with something other than JS!) would be a more simpler:

/jquery
/dojoroot
/YUI
/proj1
/proj2
/proj3
/proj4
/proj5
/proj6
/proj7
/proj8

and every project use what it wants when it needs.

That's why Vendor branch is not a panacea, and that's confirmed by Netbeans itself since it don't force to use it under PHP, JAVA, C++, and so on. Only Ajax developers has to face this BUG and P1 is a good choice for a design ERROR.
Comment 7 Bambara 2013-08-20 22:01:20 UTC
Hello,

I have been using this feature in Eclipse for the past years and it works realy well there.

I realy like Netbeans handling of different scopes and objects way ahead of Eclipse but this missing feature realy anoys me.

I do server side JS dev and I have a set of libraries that I use, I don't want to copy them one by one in my project, I have no interest in jQuest ExtJS and so on.

With this feature Netbeans can turn into a true IDE for Javascript which start to be a very common language for server side stuff as well with NodeJS and other stuff.

Thanks,
Comment 8 NukemBy 2014-02-14 22:16:50 UTC
Title of this issue is a bit misleading - I would rename if to "Add support for JavaScript global library manager", but ... there is already such bug reports 

"javascript framework support" (2010-12-27 22:30 UTC by Flyingmana@netbeans.org)
https://netbeans.org/bugzilla/show_bug.cgi?id=193855

Add support for libraries. (Reported:	2007-11-19 10:47 UTC by Jan Jancura)
https://netbeans.org/bugzilla/show_bug.cgi?id=122265

This thread looks to be the most recent one, so here is my use-case ...

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 

I have my own JavaScript library and it is developed in context of one MAVEN project. That MAVEN project is included into multi-module MAVEN project which collects resources (JavaScript files as well) from multiple modules into single place at runtime. Having this in mind, I'd like to have support for shared code completion for JS across all these projects. I would say that following will work for me ...

1. Explicit referencing of required global JavaScript files somewhere in Tools->JavaScript Libraries or Tools->Options->Editor->Code Completion->JavaScript

2. Having an option for JavaScript editor to share Code Completion/Intellisense information extracted from JavaScript files (all ones assigned to text/javascript MIME type in Tools->Options->Miscelaneous->Files) in All currently open projects or Currently open javascript files (even if they are not included into any project).

Having both options available in parallel would be excelent.