Integrating Web Technologies in Eclipse
Total Page：16
File Type：pdf, Size：1020Kb
Integrating Web technologies in Eclipse & In this paper we describe an approach and an implementation for integrating Web technologies in Eclipse, a Java- and component-based platform. First, we support embedding of UI (user interface) artifacts that are developed using either widget or markup technologies. Second, we provide support for DOM (Document Object Model) J. Ponzo programming. We implement this approach by bridging the relevant foundation O. Gruber technologies—COM (Component Object Model) and XPCOM (Cross Platform Component Object Model)—which allows us to embed the engines of the two major browsers, Internet Explorer and Mozillat. We discuss several possible applications of this work, such as seamless access to online help systems and Web-based development of administrative tools. The world of end-user applications has been divided integration. Recently, Eclipse has evolved toward between Web applications and traditional applica- the concept of a Rich Client Platform, the integration 2 tions. Whereas traditional applications use widget not only of tools but also of applications. With this technologies for their user interface (UI), Web goal in mind, we feel that it is particularly important applications use markup rendering technologies, to appeal equally to Java** and Web developers. such as HTML (Hypertext Markup Language), CSS (Cascading Style Sheets), and scripting (e.g., Java- To that end, we integrate Web technologies in Script**). The advantages of combining both tech- Eclipse. Here we use the term ‘‘integration’’ to imply nologies in a single application has recently been a tighter relationship than simple ‘‘embedding.’’ The demonstrated in products such as Lotus Notes*, integration is performed in two steps: (1) embedding Quicken**, and Microsoft Money 2005. It is our goal of UI artifacts, and (2) support for Document Object 1 to offer these advantages in the Eclipse platform. Model (DOM) programming. The UI artifacts that can be embedded in the Eclipse Workbench are Eclipse, an open-source project that started as a developed by using either widget or markup platform for developing IDEs (Integrated Develop- ment Environments), is a platform for developing ÓCopyright 2005 by International Business Machines Corporation. Copying in printed form for private use is permitted without payment of royalty provided applications based on software components. that (1) each reproduction is done without alteration and (2) the Journal Through components, Eclipse provides integration reference and IBM copyright notice are included on the first page. The title and abstract, but no other portions, of this paper may be copied or distributed frameworks such as the Eclipse Workbench for UI royalty free without further permission by computer-based and other information-service systems. Permission to republish any other portion of the integration and the Eclipse Workspace for data paper must be obtained from the Editor. 0018-8670/05/$5.00 Ó 2005 IBM IBM SYSTEMS JOURNAL, VOL 44, NO 2, 2005 PONZO AND GRUBER 279 technologies. The DOM is the in-memory parsed tree forward but rather numerous mappings are auto- of a markup document—most often HTML. Web matically generated from the corresponding browser engines dynamically render the DOM as COM/XPCOM IDL (Interface Description Language) they parse Web pages. DOM programming is the by a COM/XPCOM-IDL-to-Java-Class generator that dynamic creation or manipulation of the in-memory we created. Second, we use these Java APIs to tree, thereby controlling the rendering of the docu- implement the W3C DOM2 API. ment. DOM programming is also used for handling user-interface events. Integrating Web technologies significantly enhances the Eclipse platform. First, it enables the UI For our integration approach in Eclipse, we preserve embedding of Web pages. This provides in-place the design principle of the Standard Widget Toolkit integration of Web assets, such as Web applications 1 (SWT), the cross-platform widget toolkit of Eclipse. or Web-based tools. One typical example is the SWT implements a thin veneer over existing native integration of the HTML help system. Second, it widget capabilities. This thin veneer varies with the enables a choice of UI technologies for plug-in environment because it depends on the windowing developers. Eclipse views or perspectives may be system and on the native widget toolkit. This developed using either markup or widget technolo- approach is well suited for embedding Web brows- gies. Java logic can interact with either Java widgets ers. Both Internet Explorer (IE) and Mozilla** or HTML markup, providing a rich, seamless user provide embeddable engines that can be exposed to experience that combines the strengths of both Java. We extend SWT to make use of these engines widget and markup paradigms. Our work opens up 6 for the parsing and rendering of HTML documents Eclipse to Dynamic HTML (DHTML) for Java. as well as for providing full DOM application programming interfaces (APIs). We provide brows- The rest of the paper is structured as follows. In the er-specific DOM APIs, thus giving access to the full next section we review the necessary background on capabilities of each browser when needed. the Web browser technologies used by the IE and Mozilla browsers. In the following section we In addition, it is important to promote a portable describe the design challenges we faced for inte- programming model for Web technologies, rather grating Web technologies in Eclipse. We first than a browser-specific one. To achieve this goal, describe the bridging to the relevant foundation 3 we also provide the DOM 2 Core API defined by the technologies—COM and XPCOM. Then, building on World Wide Web Consortium (W3C**). By using these bridges, we discuss our approach to the this API (W3C DOM2 for short), we ensure that embedding of UI artifacts and to supporting DOM Eclipse developers have portability across Web programming. In the section ‘‘Examples,’’ we browsers and operating systems (Windows**, Li- discuss several possible applications: online help nux** and Mac OS**). systems, integrating development or administrative tools, and using Eclipse as an advanced application Our approach is technically an extension of the platform. In the last two sections we cover related approach for integrating native applications pio- work and conclusions. neered by SWT. SWT exposes a bridge in Java for the Microsoft native component framework COM WEB BROWSER BACKGROUND 4 (Component Object Model). Our approach also Web browsers have evolved from stand-alone supports the Mozilla component framework, markup viewers for hypermedia application plat- 5 XPCOM (Cross Platform Component Object Model). forms to today’s desktop browsers—Mozilla and With this foundation in place, it is relatively IE—which offer embeddable engines and the bene- straightforward to define a SWT widget for embed- fits of component frameworks. ding the different Web browsers, thus providing a common API for navigating HTML pages. However, XPCOM is the Mozilla binary framework for providing a common DOM API across Web browsers components and services. The Mozilla embeddable 7 is more challenging because of the slight variations engine, Gecko, is an XPCOM component. XPCOM is between the existing DOM APIs in IE and Mozilla. derived from Microsoft COM and runs on all We approach this in two steps. First, we map the operating systems that Mozilla supports, including native browser DOM APIs to Java. These straight- Windows, Linux, and Mac OS. Mozilla as a whole is 280 PONZO AND GRUBER IBM SYSTEMS JOURNAL, VOL 44, NO 2, 2005 designed as a collection of XPCOM components. Only after the XPCOM layer is initialized can an HTML Rendering Rendered application load Gecko. Gecko’s primary function is Engine Web Page to provide markup rendering. HTML Document HTML DOM Gecko first parses markup documents into in- HTML memory tree structures, called the Document Object Parser Model (DOM). The rendering happens within a native window, either a parent or child window, as provided by the window manager of the platform on which Gecko runs. Within Gecko, the tree is Figure 1 manipulated through a DOM API, very similar to the Web browser component one defined by the W3C consortium. Gecko then renders the DOM through its built-in support for HTML and style sheets (see Figure 1). Through the interfaces, but all interfaces of an object would DOM API, an HTML document can be created or return the same virtual table for the IUnknown incrementally modified. Whenever a DOM tree is interface. The address of this virtual table is modified, Gecko dynamically and incrementally re- considered the identity of the object. renders that tree—this dynamic rendering is the foundation of DHTML. COM objects are created by special kinds of objects known as factory objects. Factory objects, which are Gecko also supports plug-ins that can be used to normal COM objects, declare themselves to the COM handle custom tags within HTML markup. These runtime as factories and identify themselves using plug-ins are XPCOM components themselves. For globally unique identifiers. In fact, interfaces are example, when Gecko loads an HTML document, it also identified through globally unique identifiers. extracts the JavaScript tags and passes them to its These unique identifiers are used when querying an JavaScript interpreter, also an XPCOM component. object for an interface or asking the COM runtime to Gecko uses the ,embed. tag to handle browser create an instance of a class. Best practices for COM plug-ins, triggering the loading of XPCOM compo- include the rule that interfaces are immutable (once nents. published, they will not be modified). After a component is included in a released product, any Although the IE architecture is similar to Mozilla’s, follow-on version of that component preserves the it is based on COM, the Microsoft component old interfaces for compatibility, and new interfaces framework from which XPCOM is derived. The are added as necessary.