Your SlideShare is downloading. ×
0
Eclipsecon 2011 Supporting javascript toolkits with jsdt
Eclipsecon 2011 Supporting javascript toolkits with jsdt
Eclipsecon 2011 Supporting javascript toolkits with jsdt
Eclipsecon 2011 Supporting javascript toolkits with jsdt
Eclipsecon 2011 Supporting javascript toolkits with jsdt
Eclipsecon 2011 Supporting javascript toolkits with jsdt
Eclipsecon 2011 Supporting javascript toolkits with jsdt
Eclipsecon 2011 Supporting javascript toolkits with jsdt
Eclipsecon 2011 Supporting javascript toolkits with jsdt
Eclipsecon 2011 Supporting javascript toolkits with jsdt
Eclipsecon 2011 Supporting javascript toolkits with jsdt
Eclipsecon 2011 Supporting javascript toolkits with jsdt
Eclipsecon 2011 Supporting javascript toolkits with jsdt
Eclipsecon 2011 Supporting javascript toolkits with jsdt
Eclipsecon 2011 Supporting javascript toolkits with jsdt
Eclipsecon 2011 Supporting javascript toolkits with jsdt
Eclipsecon 2011 Supporting javascript toolkits with jsdt
Eclipsecon 2011 Supporting javascript toolkits with jsdt
Eclipsecon 2011 Supporting javascript toolkits with jsdt
Eclipsecon 2011 Supporting javascript toolkits with jsdt
Eclipsecon 2011 Supporting javascript toolkits with jsdt
Eclipsecon 2011 Supporting javascript toolkits with jsdt
Eclipsecon 2011 Supporting javascript toolkits with jsdt
Eclipsecon 2011 Supporting javascript toolkits with jsdt
Eclipsecon 2011 Supporting javascript toolkits with jsdt
Eclipsecon 2011 Supporting javascript toolkits with jsdt
Eclipsecon 2011 Supporting javascript toolkits with jsdt
Eclipsecon 2011 Supporting javascript toolkits with jsdt
Eclipsecon 2011 Supporting javascript toolkits with jsdt
Eclipsecon 2011 Supporting javascript toolkits with jsdt
Eclipsecon 2011 Supporting javascript toolkits with jsdt
Eclipsecon 2011 Supporting javascript toolkits with jsdt
Eclipsecon 2011 Supporting javascript toolkits with jsdt
Eclipsecon 2011 Supporting javascript toolkits with jsdt
Eclipsecon 2011 Supporting javascript toolkits with jsdt
Eclipsecon 2011 Supporting javascript toolkits with jsdt
Eclipsecon 2011 Supporting javascript toolkits with jsdt
Eclipsecon 2011 Supporting javascript toolkits with jsdt
Eclipsecon 2011 Supporting javascript toolkits with jsdt
Eclipsecon 2011 Supporting javascript toolkits with jsdt
Eclipsecon 2011 Supporting javascript toolkits with jsdt
Eclipsecon 2011 Supporting javascript toolkits with jsdt
Eclipsecon 2011 Supporting javascript toolkits with jsdt
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Eclipsecon 2011 Supporting javascript toolkits with jsdt

2,374

Published on

JSDT is the JavaScript IDE now provided within the Web Tools Platform, a vendor neutral, standards oriented basis for web tools in Eclipse. Being vendor neutral, however, means not playing favorites …

JSDT is the JavaScript IDE now provided within the Web Tools Platform, a vendor neutral, standards oriented basis for web tools in Eclipse. Being vendor neutral, however, means not playing favorites among the many JavaScript toolkits being used to create Web 2.0 sites. Just as WTP offers mechanisms for application server vendors to have first class support within Eclipse, so too does JSDT offer extension points for enriching the experience when working with your JavaScript toolkit of choice. This presentation covers the limitations to JSDT's built-in language support and how to aid it in inferring type information from your sources and leveraging custom documentation formats.

Published in: Education
0 Comments
0 Likes
Statistics
Notes

  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
2,374
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
50
Comments
0
Likes
0
Embeds 0
No embeds
Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • This is “Supporting Javascript Toolkits – and its intended for developers to discover the underlying JSDT framework, and also the available extensions required to support the various Javascript toolkits and libraries.
  • WTP’s Original Javascript editor – Available in WTP 2.0 (Europa) - based on WTP’s SSE Framework
  • The original editor, based on WTP’s source editor framework, - provided simple syntax coloring, content assist on a limited list of well know browser objects. - It supported not only JS files, but also integration within the existing HTML and JSP editors
  • But restrictions start to pile up: - The editor provided no pluggable facility to upgrade syntax level as Javascript versions were released, - There was no extension mechanism for adding more objects / classes/ functions/ libraries. - No model existed to help provide features such as advanced content assist, hover help, refactoring, any meaningful semantic validation
  • JSDT began as a project by a small team within IBM Research. It became part of the Eclipse ATF project right around the time we started turning a critical eye to WTP’s JavaScript support and finding it lacking when it came to real world scenarios. JSDT’s abilities already surpassed what was in WTP 2.0, and once it was able to provide a similar level of integration with the other source editors, it was moved from ATF to become part of the WTP 3.0 release
  • As with many IDEs built on top of Eclipse, JSDT followed the tried-and-true route of starting as a fork from the JDT sources, in this case from a late JDT 3.3 milestone.
  • Among other changes, - parser was modified to support JavaScript syntax, - the compiler altered to not write out byte codes , - the Semantic analyzer and Search was updated, - the type resolution in the compiler altered to support the less stringent demands of JavaScript.
  • The core jsdt package has only the platform as a pre-req.
  • Components (Features) from WTP’s Common and Source Editing projects that support editing web pages also include the necessary plug-ins for integrating JSDT.
  • Java, in many ways, is designed for IDE support. A statically typed language, a Java compiler can relatively easily determine the type of a variable, and find whether a message being sent will be understood by that variable, or whether a field access will actually resolve properly. The evaluation of expressions is clearly defined for a given set of operands. Methods can only be defined to return objects of one type or satisfying one interface. The ordered classpath and source file layout ensure that for a given fully qualified type name, the matching source or binary file must be in one location relative to an entry in the classpath, which must searched in that order. All of the members of a type must also be defined in that single file or otherwise inherited from a supertype listed with the type declaration, for which there is a reserved keyword.
  • The dynamic (“duck”) typing allows for incredibly expressive and functional code to be written a very compact form. I come from a smalltalk background, and loved the elegance and simplicity But, this freedom can be daunting for programmers used to static type restrictions, and increasingly hard to navigate as the code base grows ever larger.
  • So how does JSDT tackle these “shortcomings” in the language to provide a high quality experience similar to that provided by JDT, but for JavaScript?
  • JavaScript doesn’t define a standard for how to work with content across multiple files. Web pages can define which script files they use statically.
  • or have that list of inclusions modified through client-side scripting or server-side scripting
  • The solution JSDT employs is to reuse the familiar JDT Build Path model, this time an an Include Path for folders whose files’ contents are simply always known to each other.
  • JSDT thus also inherits JDT’s support allowing plug-ins to contribute reusable libraries and containers to simplify working within teams.
  • the APIs for looking up types no longer restrict results with the expectation that a type be represented in one file—the model returns as many types of the same name as there are files declaring them,
  • or properties of them based on information provided from the inference engine - So what is an Inference engine?
  • Whether someone thinks JavaScript has or doesn’t have Types, it’s still a useful approach to working with source code in an IDE. A Java compiler, in one of its earlier stages, will convert the source into an Abstract Syntax Tree (AST). This representation models the types, methods, and fields, all the way down to individual statements and the expressions that compose them. The expressions declare which types are in use. JSDT also creates an AST, but then attempts to perform type inference using static analysis of the syntax tree along with any inline documentation. Common coding practices are recognized and used to infer types and their properties, those findings then used to drive IDE functions such as the Outline view, Content Assist, explorer views, and Search. This analysis is encapsulated in what we refer to as an Inference Engine . JSDT’s built-in inference engine recognizes the prototype keyword, types of literals, constructor-like usage of functions, type information documented using JSDoc, and more cases I won’t list here. It’s at this point that JSDT’s support for AJAX toolkits falters, many libraries having a unique or specific way to define types that eludes detection by our inference engine. And here’s where the most significant of our extension points comes into play: org.eclipse.wst.jsdt.core.inferrenceSupport
  • This extension point allows a plug-in developer to contribute their own Inference Engine to run on a file for analysis. That engine has access to the internal compiler AST, allowing it to add inferred types and members to JSDT’s knowledge of a particular file.   org.eclipse.wst.jsdt.core.infer.IInferEngine – the interface all inference engines must implement org.eclipse.wst.jsdt.core.infer.InferEngine – our default implementation, largely built as an ASTVisitor. org.eclipse.wst.jsdt.internal.compiler.ast.CompilationUnitDeclaration – an object that provides the inference engines access to a single file’s location
  • org.eclipse.wst.jsdt.core.infer.InferredType – represents a “type” as a JavaScript developer might think of it. If a toolkit doesn’t use constructor functions directly, an engine can still add types so that they’re available for content assist and search. An inferred type is limited to knowing the fields and methods contained in the one file that the CompilationUnitDeclaration holds. InferredTypes are expected to be added for all referenced types and all declared types, even if it’s just for adding one property to a type that’s formally declared in a different file. Types that don’t have names (object literals) should also be added for completeness.
  • org.eclipse.wst.jsdt.core.infer.InferredMethod – represents any property of an object that points to a function by encapsulating that function expression. Different InferredMethods on different InferredTypes are allowed to point to the same function. Static analysis of the function and its documentation is used by the inference engine to set up type information for the method’s return type and argument types
  • org.eclipse.wst.jsdt.core.infer.InferredAttribute – a property of an object that is not a function, static analysis and documentation is used by the inference engine to set up type information for the attribute.
  • When JSDT is indexing your sources, it’s using these objects to help populate its Search Index. They’re also converted, as needed, into the IJavaScriptElements used to populate JSDT’s model and shown throughout JSDT’s UI. The declared engines have the critically important duty of thoroughly finding all of the declared types and picking the right offsets for the name of the inferred types and members, as that will be used when navigating with hyper-links, showing search results, and eventually proper Refactoring support. Without good engines, all you really get is syntax coloring.
  • Multiple inference engines can be run on the same file, allowing for the supporting of mixed coding styles and the derivation of type information from any number of inline documentation formats. Work is ongoing in the area of getting engines to coexist properly, and avoid duplicating both results and performance problems.
  • JSDT offers a general view for rendering documentation written in JSDoc, a format chosen in part because it is not tied to a particular toolkit and also for its resemblance to JavaDoc.
  • Tellingly, it’s not called the JSDoc view because as with the type inference mechanism, JSDT doesn’t assume that all documentation is written as JSDoc.
  • Enter the org.eclipse.wst.jsdt.ui.documentationProvider extension point. This extension point allows a plug-in developer to contribute a class for providing the text documentation associated with a type or member, as well as for rendering it into HTML for use in the Documentation view--an implementer of org.eclipse.wst.jsdt.ui.IDocumentationReader It is expected to provide a Reader for the documentation text as well as a Reader for the documentation text converted into HTML for a styled display.
  • “ Some” upgrades to ECMA5 will be finished by Indigo
  • Validation: working on filtering out problems in JSDT for unresolved fields/methods/types, duplicate variables JavaScript has a single function scope
  • Links: http://wiki.eclipse.org/index.php/JSDT http://www.ibm.com/developerworks/library/os-eclipse-jsdt/
  • Links: http://wiki.eclipse.org/index.php/JSDT http://www.ibm.com/developerworks/library/os-eclipse-jsdt/

    • Transcript

    • 1. Supporting JavaScript Toolkits with JSDT Chuck Bridgham, WTP Java EE Project Lead, PMC [email_address] Nitin Dahyabhai, WTP SSE, JSDT Project Lead [email_address]
    • 2. JavaScript Development Tools
      • Didn’t we already have JavaScript tools?
      • History of JSDT
      • How JavaScript is not Java, and how JSDT handles those differences
      • Helping JSDT handle those differences
      • What extensions are available
      • What’s going on in JSDT project today
    • 3. Why not our original tools?
      • WTP already had an editor, didn’t it?
    • 4. Why not our original editor?
      • Syntax coloring
      • Content assist with built-in browser objects
      • Integration with web page editors
    • 5. Why not our original editor?
      • Syntax coloring
      • Content assist with built-in browser objects
      • Integration with web page editors
      • Trapped at old syntax level
      • Stuck with just predefined objects
      • No model to build on
      • No validation to speak of
    • 6. Where did JSDT come from?
      • IBM Research team
    • 7. Where did JSDT come from?
      • IBM Research team
      • JDT Fork
    • 8. Where did JSDT come from?
      • IBM Research team
      • JDT Fork
        • Interfaces renamed
        • Parser modified and regenerated
        • Semantic analyzer and Search updated
        • Bytecode generation disabled
    • 9. Where did JSDT come from?
      • IBM Research team
      • JDT Fork
        • Interfaces renamed
        • Parser modified and regenerated
        • Semantic analyzer and Search updated
        • Bytecode generation disabled
      • Same prereqs as JDT: just the Platform
    • 10. Where did JSDT come from?
      • IBM Research team
      • JDT Fork
        • Interfaces renamed
        • Parser modified and regenerated
        • Semantic analyzer and Search updated
        • Bytecode generation disabled
      • Same prereqs as JDT: just the Platform
      • Okay, other parts of WTP for web pages
    • 11. So why is Java suited for IDE support?
      • Statically Typed
        • Compiler resolves types with ease
      • Expression evaluation clearly defined
      • Methods returning known interface
      • Ordered Classpath and source file layout
      • Members of a type in single file, or inherited file
    • 12. How is JavaScript unlike Java?
    • 13. How is JavaScript unlike Java?
      • No CLASSPATH --which files are important?
    • 14. How is JavaScript unlike Java?
      • No rules about which files are important
      • No class keyword to rely on for Type Declarations
    • 15. How is JavaScript unlike Java?
      • No rules about which files are important
      • No class keyword to rely on
      • Types can defined in any file, any where
    • 16. How is JavaScript unlike Java?
      • No rules about which files are important
      • No class keyword to rely on
      • Types can defined in any file
      • Properties can be contributed to any Type from any file
    • 17. How is JavaScript unlike Java?
      • No rules about which files are important
      • No class keyword to rely on
      • Types can defined in any file
      • Properties can be contributed to any Type from any file
      • Dynamic typing
    • 18. How is JavaScript unlike Java?
      • No rules about which files are important
      • No class keyword to rely on
      • Types can defined in any file
      • Properties can be contributed to any Type from any file
      • Dynamic typing
      • Yet we still want to provide a JDT-like feature-rich experience
    • 19. Include Paths
      • Unpredictable script loading in web pages
    • 20. Include Paths
      • Unpredictable script loading in web pages
      • Server-side generated client scripts
    • 21. Include Paths
      • Unpredictable script loading in web pages
      • Server-side generated client scripts
      • Define a project-wide Include Path, based on JDT Build path
    • 22. Include Paths
      • Unpredictable script loading in web pages
      • Server-side generated client scripts
      • Define a project-wide Include Path, based on JDT Build path
        • Introduce Source folder and Library notions, dependencies across workspace projects
        • Reusable libraries and containers
    • 23. It’s still not Java
      • No class keyword to rely on
    • 24. It’s still not Java
      • No class keyword to rely on
      • Types can defined in any file
    • 25. It’s still not Java
      • No class keyword to rely on
      • Types can defined in any file
      • Properties can be contributed to any Type from any file
    • 26. That can be a good thing.
      • No class keyword to rely on
      • Infer types based on usage
      • Need to make it extensible
    • 27. Type Inference
      • org.eclipse.wst.jsdt.core.inferrenceSupport
      • org.eclipse.wst.jsdt.core.infer.IInferEngine
      • org.eclipse.wst.jsdt.core.infer.InferEngine
        • Walks the AST to discover Types, Methods, and Fields
        • Use JSDoc when found
        • One file at a time
      • org.eclipse.wst.jsdt.internal.compiler.ast.CompilationUnitDeclaration
    • 28. Type Inference – the model
      • org.eclipse.wst.jsdt.core.infer.InferredType
        • Specific text positions needed for desired future refactoring support
        • Only responsible for information in one file
        • Required for all references and declarations
        • Incomplete and inaccurate InferredType information is the largest cause of semantic validation problems.
    • 29. Type Inference – the model
      • o.e.w.jsdt.core.infer.InferredMethod
        • Points to a function
        • May hold “modifier” information in the future
    • 30. Type Inference – the model
      • o.e.w.jsdt.core.infer.InferredAttribute
        • Points to anything that’s not a function
        • May also hold “modifier” information in the future
    • 31. Type Inference
      • o.e.w.jsdt.core.infer.Inferred* help populate the Search Index and JavaScript Model, so good InferEngines are key.
    • 32. Type Inference
      • o.e.w.jsdt.core.infer.Inferred* help populate the Search Index and JavaScript Model, so good InferEngines are key.
      • Use the provided library stubs as examples.
      • Multiple InferredTypes and ITypes in the model are okay.
      • They’re merged in the UI when possible.
    • 33. Supporting Documentation
    • 34. Supporting Documentation
      • It’s not all JSDoc
    • 35. Supporting Documentation
      • It’s not all JSDoc
      • org.eclipse.wst.jsdt.ui.documentationProvider extension point
      • org.eclipse.wst.jsdt.ui.IDocumentationReader
        • Given IType/IField/IMethod
        • Supplies Reader for raw documentation text
        • Supplies Reader for HTML-ified documentation to be shown in hovers and Documentation View
    • 36. What’s upcoming?
      • Smart Insert functionality in web pages
    • 37. What’s upcoming?
      • Smart Insert functionality in web pages
      • Parser updates for newer language versions
    • 38. What’s upcoming?
      • Smart Insert functionality in web pages
      • Parser updates for newer language versions
      • Stabilize AST Rewrite (pending Parser updates)
    • 39. What’s upcoming?
      • Smart Insert functionality in web pages
      • Parser updates for newer language versions
      • Stabilize AST Rewrite (pending Parser updates)
      • Less presumptuous validation
    • 40. What’s upcoming?
      • Smart Insert functionality in web pages
      • Parser updates for newer language versions
      • Stabilize AST Rewrite (pending Parser updates)
      • Less presumptuous validation
      • HTML5 browser library stubs
    • 41. Want to get involved?
      • Ask more questions in eclipse.webtools newsgroup / http://eclipse.org/forums/eclipse.webtools
      • Check-out sources from our public CVS
      • File bugs and RFEs under Classification:Webtools / Product:JSDT
      • Writing plug-ins for your favorite toolkits? Let us know how to make it easier for you.
    • 42. Thanks!
    • 43. Legal Notices
        • Copyright © IBM Corporation, 2011. All rights reserved. Any source code in this presentation is made available under the EPL, v1.0, remainder of the presentation is licensed under Creative Commons Att. Nc Nd 2.5 license.
        • IBM and the IBM logo are trademarks or registered trademarks of IBM Corporation, in the United States, other countries or both.
        • Rational and the Rational logo are trademarks or registered trademarks of International Business Machines Corporation in the United States, other countries or both.
        • Oracle, Java, JavaScript, and all Java-based marks, among others, are trademarks or registered trademarks of Oracle Corporation in the United States, other countries or both.
        • Eclipse and the Eclipse logo are trademarks of Eclipse Foundation, Inc.
        • Other company, product and service names may be trademarks or service marks of others.
        • THE INFORMATION DISCUSSED IN THIS PRESENTATION IS PROVIDED FOR INFORMATIONAL PURPOSES ONLY. WHILE EFFORTS WERE MADE TO VERIFY THE COMPLETENESS AND ACCURACY OF THE INFORMATION, IT IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, AND IBM SHALL NOT BE RESPONSIBLE FOR ANY DAMAGES ARISING OUT OF THE USE OF, OR OTHERWISE RELATED TO, SUCH INFORMATION. ANY INFORMATION CONCERNING IBM'S PRODUCT PLANS OR STRATEGY IS SUBJECT TO CHANGE BY IBM WITHOUT NOTICE.

    ×