Bugzilla – Full Text Bug Listing
| Summary: | JavaScript object-oriented | ||
|---|---|---|---|
| Product: | z_Archived | Reporter: | Martin Burchard <webtools> |
| Component: | Webtools.WST.Javascript | Assignee: | David Williams <david_williams> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | am, apeller, asqueella, bugs.eclipse.org, clement.idelon, juan.lanus, levik, pombredanne |
| Version: | unspecified | Keywords: | helpwanted |
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
Martin, I agree -- and I think from your comments you'd agree this is more a "feature request" than a "bug" ... so I'm changing to enhancment severity. (please change back if you disagree). Frankly, though, no one on core team could do this work, so am marking as "helpwanted". I'm wondering if the outline is currently built by parsing the .js file - since Javascript is inherently runtime, one would probably need to interpret the code (in the context of the entire project no less - what if it's pulling in classes from other js files?) in order to arrive at meaningful results. Other approaches would probably be nothing more than stop-gap fixes that will not address the full plethora of JS coding styles out there. I think you could go a long way and satisfy many developers based on parsing for patterns in the code, such as the one described (as the old sourceforge jseditor did) True, properties and methods could be defined at runtime, but they might even change over the course of execution, so there would not truly be a static outline to look at anyway -- if you want that, you really need a debugger! The current parser is really a tokenizer and lacks an abstract syntax tree. Perhaps a stop-gap measure to recognize only the pattern shown below would be a good first step? Rendering "var" statements in the outline, regardless of scope, seems to conflict with the propsed o-o outline view, and I propose that it be disabled, or perhaps this could be controlled via preferences? I don't think that this is impossible to achieve by using Rhino. I played around with this a little bit today, after seeing this bug today, to investigate if it would be possible to do and I think it is. I'm not an Eclipse programmer so I don't know what is needed to integrate this into Eclipse but I managed to create a syntax tree for a set of JavaScript files and print it. It can detect fields and method of classes and check if they are static or not. If you follow the coding standard to let private fields and methods start with _ it can also detect this. The only problem that I have right now is to detect which classes that exists (I used a predefined list of classes) but this can probably be found by using the methods of Rhino but I haven't found this yet. If anybody who knows more about Eclipse is interested, I can help with this feature. Yes, I thought about that approach also. Rather than building a parser, you could use Rhino as the parser and use its syntax tree. I believe this is just a compile phase and not a runtime phase, though. You probably wouldn't want to execute the code for performance reasons and it generally shouldn't be necessary to do an eval? Also, I'm not sure what the implications would be of including a Rhino dependency in the current code. dup of #88902? Just checked out the old SF.net jseditor (from https://sourceforge.net/projects/jseditor/ )... It seems like that one does a very decent job of detecting prototype assignments as OO constructs as Adam said, but tends to fall short in most other aspects (code completion, etc). Given that (as the page claims) the torch was passed on to WTP, perhaps the outline-building code could be stripped out of that plugin and brought over to the new JS editor? *** Bug 204349 has been marked as a duplicate of this bug. *** I'm doing a mass resolve of all open bugs in the wst.javascript component. Resolving to "won't fix". The reason is that the old wst.javascript component is being removed this release, and replaced by the wst.jsdt component. So ... if any owners of these wst.javascript bugs see the same problem in the wst.jsdt code, then please open a new bug on that component. Apologies we can't check each ourselves, but there's just too many (and too few people) so we'll need community help. Just glancing, I know for sure many will no longer be bugs but some may still be legitimate requests even in the new JSDT code. |
The JavaScript Editor seems to ignore everything in JavaScript that is written object-oriented. Example: function person() { this.name = ''; this.age = 0; }; person.prototype.init = function(name, age) { this.name = name; this.age = age; }; The Editor has no support for code completion when using own objects. Also the outline can't handle such JavaScript objects. This would be a nice feature because OO in Javascript is very powerfull.