JLPEX: Class TestParser1

Overview

Package

Class

Use

Tree

Deprecated

Index

Help

PREV CLASS NEXT CLASS

FRAMES NO FRAMES

SUMMARY: INNER | FIELD | CONSTR | METHOD

DETAIL: FIELD | CONSTR | METHOD

com.ibm.lpex.samples
Class TestParser1

java.lang.Object
  |
  +--com.ibm.lpex.core.LpexCommonParser
        |
        +--com.ibm.lpex.samples.TestParser1

All Implemented Interfaces:: LpexConstants, LpexParser

public class TestParser1
extends LpexCommonParser

Sample LpexCommonParser parser: STEP 1 - minimum code.

This is a sample skeleton for a parser extending LpexCommonParser. It shows the minimum code needed to implement such a parser. TestParser2 will build on this foundation to carry out a simple parsing of comments in text files.

When a new file is opened as a document, the editor looks for the parser associated with that file's name extension. Parsers may be set up via the updateProfile.parserClass, updateProfile.parserAssociation, and updateProfile.parser editor parameters.

For example, opening sample.cpp may point the editor to the parser class "CppParserWIN.class". Once found, the editor will load this class - CppParserWIN's constructor will instantiate one object for the newly-created document view -, and then call one of its public methods to carry out a total parse on the document sample.cpp. Afterwards, each time the user modifies (edits) sample.cpp, a method in CppParserWIN will be called to do an incremental parse on the changes in the document.

Whatever the parser chooses to do is at its discretion. Usually, a parser will scan the file to understand its structure, and colorize the various tokens as an aid to the programmer editing that type of files: say, keywords in blue, numbers in red, and comments in green. While the user is editing the file, the parser will 'play catch-up' and maintain its information of the file structure (and the displayed token colours) up-to-date.

At a minimum, a parser written by extending class LpexCommonParser should have a constructor, and implement two methods (defined as abstract in LpexCommonParser): parseAll() and parseElement(). LpexCommonParser handles the rest.

 public class TestParser1 extends LpexCommonParser
 {
    public TestParser1(LpexView lpexView) {super(lpexView);}
    public void parseAll() {}
    public void parseElement(int element) {}
 }

See the rest of the documentation below. It shows and explains the code of this example.

TestParser2 will do some real parsing, building on this framework.

See Also:: LpexCommonParser, TestParser2

Constructor Detail

TestParser1

public TestParser1(LpexView lpexView)

The parser's constructor. First thing to do in here is to call the superclass constructor, i.e., LpexCommonParser's. Next, whatever else may be needed by the parser should be initialized (more on this in the next example, when the parser will actually parse).

 public TestParser1(LpexView lpexView)
 {
    super(lpexView);
 }

One instance of the parser controls one LpexView of a document. When several edit views are created for the same document, several parser objects will be instantiated, one for each view, and each will be called to parse the document.

Parameters:: lpexView - the LpexView object associated with this parser object.

Method Detail

parseAll

public void parseAll()

Total parse. The parser is called here to parse the entire document, immediately after it has been loaded in the editor.

Nothing is being done here right now:

 public void parseAll()
 {
 }

Overrides:: parseAll in class LpexCommonParser

parseElement

public void parseElement(int element)

Incremental parse. This call-back method is invoked by the editor to incrementally parse changes to the document: some new text was typed in, a line was deleted, a block operation (copy / move / delete) was performed, etc.

Nothing is done here right now, therefore there is no visible effect on the editing:

 public void parseElement(int element)
 {
 }

Overrides:: parseElement in class LpexCommonParser

Parameters:: element - the element whose committed change triggered the parse, or the element that precedes / follows a deleted block. The parser may identify other neighbouring elements that will have to be reparsed as a unit.