Community
Participate
Working Groups
Build Identifier: helios for java ee developers i have a static web project, test-html, with a html file. and a js project, test-js, in the include path of the web project. i expected that: 1. a function from a js file of the js project test-js be seen by the content assist in the <script> tags of an html file in the web project. Apparently only functions that are interpreted as constructors ( either by including this.prop="prop value" in function body or by using statements like myfunction.prototype.prop=... or var x= new myfunction() ) are seen. 2. the web project could be deployed (right click/ debug as/ debug on server) on a server like "Basic / HTTP Server". When i right click/debug as/debug on server, and deploy it, the internal browser lanunches with "http://localhost/test-html/" and "cannot display page" message. 3. most important of all, i expectd that test-js, could end up in the deployed test-web's web content layout. Setting this in "Deployment Assembly" by mapping test-js project to something like "/javascript" does nothing. This setting even dissapears after setting it in test-html's preferences. Should this be normal behaviour of "Deployment Assembly". Is it possible to export a references js project into a web project's web layout on a http server? What are the steps to follow? Reproducible: Always
Created attachment 172962 [details] basic http server not running static web project
Created attachment 172963 [details] "alfa" function is not seen by the content assist
Created attachment 172964 [details] dependecy
Your web page has no reference to alerts.js, which is the only provider of other al* functions that I can see. "Deployment Assembly" and Debug on Server are not JSDT functions. Moving to Java EE.
(In reply to comment #4) > Your web page has no reference to alerts.js, which is the only provider of > other al* functions that I can see. > "Deployment Assembly" and Debug on Server are not JSDT functions. Moving to > Java EE. A) you are correct. But: js files in "test-html/webcontent" (neighbours of index.html) are considered (their functions visible to content assist) even if not included with a <script> tag. Is this difference among js scripts (their provenience) a normal behaviour? B) i just see that, in index.html a non declared function call like: <script language="javascript"> inter(); //declared in test-html/webcontent/test.js, even if test.js //not included with <script> asa(); //non-declared function neither in test.js or test-js </script> is tolared. Is there an option to activate in html validator?
A) By the way, how could i insert a reference to alerts.js like <script src="./prefix-by-what/alerts.js"></script> Since i don't know how test-js will end up (if at all) in the layout of test-html.
(In reply to comment #4) > Your web page has no reference to alerts.js, which is the only provider of > other al* functions that I can see. > "Deployment Assembly" and Debug on Server are not JSDT functions. Moving to > Java EE. And as i said, event if alerts.js is not include in the web page, the content assist of the web page sees function in aelrts.js that are constructors. So i see a discrimination between non-included classic functions and non-included constructor functions. So apparently it won't be a question of alerts.js visibility since it sees, for example: "level.one"
Created attachment 173033 [details] non-included constructor functions seen
Created attachment 173034 [details] non-included by <script>, neighbour js function seen
The only thing in your list that applies to JSDT is scenario #1. I am able to reproduce that problem and am investigating it now. I am targeting fix for 3.2.1.
(In reply to comment #10) > The only thing in your list that applies to JSDT is scenario #1. > I am able to reproduce that problem and am investigating it now. > I am targeting fix for 3.2.1. OK. So the solution suggested in comment #4 is not correct, right?
(In reply to comment #1) > Created an attachment (id=172962) [details] > basic http server not running static web project The point 2. in my intitial comment is not valid. In fact there must be an "external" http started, like Tomcat or Apache. And this kind of server runtime is just "attaching/seeing" the external one. In my case, there was no http server running (on that port) and that's way the page was not displaying.
(In reply to comment #10) > The only thing in your list that applies to JSDT is scenario #1. > I am able to reproduce that problem and am investigating it now. > I am targeting fix for 3.2.1. Chris, what about point A) in comment #6 and point B) in comment #5?
Our general policy with JS content assist in webpages is to show anything we can find on the project JS include path. In this cross project case that was not working correctly. JSDT does not care what script includes you use on webpages to provide content assist. We only care about the project include path. Currently testing a fix for this cross project case.
(In reply to comment #14) > Our general policy with JS content assist in webpages is to show anything we > can find on the project JS include path. > In this cross project case that was not working correctly. > JSDT does not care what script includes you use on webpages to provide content > assist. We only care about the project include path. > Currently testing a fix for this cross project case. OK, so comment #4 is an wrong suggestion. It's got nothing to do with <script> includes. What about point 3?
"Deployment Assembly" is a function of the Java EE Tools, unrelated to JSDT Project Include Paths. You should open a separate bug there.
(In reply to comment #16) > "Deployment Assembly" is a function of the Java EE Tools, unrelated to JSDT > Project Include Paths. You should open a separate bug there. OK. Thank you very much.
Created attachment 173656 [details] patch
Patch removes the unneeded and overly restrictive checks for included files when attempting content assist in web pages. This fix allows any JS file on the project include path to be found by content assist in web pages. We do not require an explicit source include.
Thanks a lot. I'm not Eclipse expert, how do i use this patch file?
That is a source patch, it can only be used if you are building your Eclipse from source. If not, you'll need to wait until 3.2.1 is released in a few weeks.
OK, thanks, i will wait. I'm not able to build a WTP p2 repository archive from the sources.
* Explain why you believe this is a stop-ship defect. Or, if it is a "hotbug" (requested by an adopter) please document it as such. If the user stores JS files in a project A and want to use them in project B we provide no content assist even if include paths linking the projects are set up. * Is there a work-around? If so, why do you believe the work-around is insufficient? The user could create a library to contain the files, but that is not very intuitive. * How has the fix been tested? Is there a test case attached to the bugzilla record? Has a JUnit Test been added? Yes, verified that it worked with the user scenario. * Give a brief technical overview. Who has reviewed this fix? Nitin reviewed the fix. We used to require the script include path for a JS script file to be in a web page for content assist to work, however we removed that requirement in 3.2. This fix does the additional work to also not require the script include for JS files in other projects as long as they are on the include path. * What is the risk associated with this fix? None. Just commented out code that checked the source include location and now allow all files in the project include path to be used in content assist.
Who asked these questions? :)
Can we close the bug? I trust this will work in 3.2.1
> * Is there a work-around? If so, why do you believe the work-around is > insufficient? > The user could create a library to contain the files, but that is not very > intuitive. The library would point to the files in the dependency project right? In order for the library evolve when the project files evolove. Given they are evoloving, it's exactly them who should be pointed by the librabry.
And something more related to a user library: i read on this post: http://o.dojotoolkit.org/forum/dojo-foundation/general-discussion/eclipse-3-4-and-jsdt-plugin that the "dojo lib was somehow preregistered on the same level as the browser libs" Is it still doable by ordinary users in wtp 3.2?
(In reply to comment #24) > Who asked these questions? :) As we're already in the process of shutting down the 3.2.1 release, there's some oversight involved in making further changes. http://wiki.eclipse.org/index.php/WTP_PMC_Defect_Review details the process if you're curious. "Closed" also has a very specific meaning in the bug's status according to https://bugs.eclipse.org/bugs/page.cgi?id=fields.html#status . Until approved by the PMC, it can not be Resolved nor transition into Closed.
(In reply to comment #27) > Is it still doable by ordinary users in wtp 3.2? That appears to be in reference to something specific in Zend Studio to support Dojo's method of declaring types. I do not know the details.
(In reply to comment #29) > (In reply to comment #27) > > Is it still doable by ordinary users in wtp 3.2? > That appears to be in reference to something specific in Zend Studio to support > Dojo's method of declaring types. I do not know the details. No, it's about plain Eclipse JSDT.
(In reply to comment #30) > No, it's about plain Eclipse JSDT. The screencast it refers to, attachment 109012 [details], quite clearly says "Zend Studio for Eclipse" at the top.
Patch checked in.
