Jump to: navigation, search

FAQ How do I implement a DOM for my language?

Revision as of 15:34, 14 March 2006 by Claffra (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

A DOM represents the structure of your programming language. Its design and implementation are dependent of the target language and follow a few simple guidelines:

  • The DOM is hierarchical in nature and directly represents concrete elements in the
program it represents

(such as the program itself and its functions, declarations, and statements). </li>

  • A DOM is used for defining context for Content Assist

(seeFAQ_How_do_I_add_Content_Assist_to_my_language_editor?. </li>

  • A DOM is useful for generating text hovers

(seeFAQ_How_do_I_add_hover_support_to_my_text_editor?. </li>

  • Creating outline views without a DOM is difficult

(seeFAQ_How_do_I_create_an_Outline_view_for_my_own_language_editor?. </li>

  • A DOM is essential in architecting and implementing support for refactoring

(seeFAQ_How_do_I_support_refactoring_for_my_own_language?. </li>

  • A program may be represented with various DOMs. In the case of eScript we have

a DOM for describing the program structure and a second DOM for the method bodies. </li>

  • A DOM is implemented as a data structure with access API. In the case of eScript, we

move Content Assist and text-hover support into the DOM nodes. This makes handling those in the editor very easy. </li>

  • A DOM can be generated in two modes:

  • The same compiler that also compiles source code can save its abstract syntax tree
(AST) and expose it for use by the editor. Using an AST is a pretty standard way to implement a computer language, and piggybacking on that infrastructure makes life a lot easier when writing your editor. This is the way the eScript editor works. </li>
  • If the underlying AST is not accessible or is to too fine-grained for use in an
editor, you may decide to implement a lightweight parser and generate a DOM more efficiently. This is the way the JDT implements its Java model. Figure 19.2 shows the inheritance hierarchy for the DOM that was develloped for the eScript’s language. As you can see, each node in the DOM extends Element. It defines the following fields:
   int startOffset, endOffset; // source positions
   Hashtable attributes;       // things like ID, label, ...
   ArrayList children;         // children of this element
   Element parent;             // the owner of this element
   String hoverHelp;           // cached value of hover help
   ...more fields....

The subclasses of Element implement useful methods:

   public String getAttributeValue(String name)
   public String getHoverHelp()
   public void getContentProposals(...., ArrayList result)   

For instance, the getHoverHelp method easily allows us to use the DOM to find the element at a given offset and then ask it for what hover help is appropriate.


    <img src=../images/dom-escript.png>

    Figure 19.2   Inheritance hierarchy for eScript’s DOM


See Also:

FAQ_How_can_I_ensure_that_my_model_is_scalable?


This FAQ was originally published in Official Eclipse 3.0 FAQs. Copyright 2004, Pearson Education, Inc. All rights reserved. This text is made available here under the terms of the Eclipse Public License v1.0.