Internal functionality of the GCF

   The GCF consists of 6 parts, whichs tasks i'll now describe in detail.

Nr Name Task/Functionality
1 XML-Parser - event-based parser, that would parse a GXL-document and call the according handler-method in the GXLDocumentHandler
2 GXLDocumentHandler - is a class to handle the events raised by the XML-parser

- an instance of this class is given to the parser so that the according handler-methods can be called

- depending on the type of event one of the methods "create(<nodeName>)", "close(<nodeName>) ", "setAttributeValue (<name>,<value>)", "createProcessingInstruction(<target>,<data>)", "createDoctypeDecl(<name>,<pubid>,<sysid>)" or "printData(<data>)" of the GXLConnector is called

- therefore an instance of the GXLConnector-class has to be given to the GXLDocumentHandler's constructor
3 GXLConnector - is a class to handle the incoming event-streams by the GXLDocumentHandler

- it would call the according method in the user's implementation of the abstract class hierarchy

- therefore it has to get the location of the user's implementation and an instance of the GXLNode-implementation (which is the root element of the document)
4 Abstract class hierarchy (GXL Meta Model) - is a reflection of the GXL Graph Model

- offers an abstract class for each GXL-construct including create<nodeName>() and close<nodeName>() methods for each possible child-element (according to the GXL Meta Model) of this construct,  a setAttributeValue(<name>,<value>)-method, a close()-method and a getChildElements()-method

- these abstract classes have to be implemented by the user

- a UML-diagram of the class hierarchy can be found here
5 GXLConverterAPI - offer static methods to centralize all framework-functions in one class

- user can initialize the parser, the GXLConnector, his implementation of the abstract classes and the GXLDocumentHandler, and start the parsing of a GXL-file
6 GXLOutputAPI - class that offers static methods for creating, writing into and closing  files (GXL and others)

How the in 1-6 explained parts of the GCF work together can be seen in the diagram below.

A pretty good method to describe the way the GCF works is to show the internal data stream in a sequence diagram.

The following diagrams show exemplary how the startElement-, endElement- and attribute-events are handled and which role each class has during this process.

 

     diagram 1 : handling of the startElement - event

In the diagram above you can see that, if the parser generates a startElement(name)-event, the GXLDocumentHandler would call the create(name) - method of the GXLConnector. The GXLConnector internally holds an abstract  tree of the document structure. Thus it "knows" the type of the current GXL-construct (given by the "name"-attribute) and the type of its  parent. Furthermore the GXLConnector "knows" the current depth of the abstract document tree. If the current depth = 0 it's clear, that the parser is at the beginning of the GXL-document and the method "create<name>()" of the GXLGXLAPIImpl has to be called. But if the current depth of the tree is > 0, the "create<name>()"-method of the parent has to be called and the depth has to be increased by 1. As it could be useful to the user, the current depth is being saved by the GXLOutputAPI and can be read with the "getCurrentDepth()"-method. To

 

   diagram 2 : handling of the endElement - event

In the second diagram you can see the endElement-event is handled analogous to the startElement-event. Here not the according close-methods have to be called and the current depth has to be decreased by 1. Important is that two close()-methods in the implementation of the abstract class hierarchy are called. The first is the close-method of the current GXL-construct and the other one is the close<name>()-method of its parent. 

 

   diagram 3 : handling of the attribute - event

The third diagram shows the handling of the attribute-event. If an attribute of type "name" is specified for the type of the current GXL-construct (according to the GXL-DTD), the "setAttributeValue(name, value)" of the implementation of the current GXL-construct would be called.

 

As the GCF is designed for the construction of two different types of converters (<...>2GXL and GXL2<...>) the question of how to "interprate" and implement the GCF for each direction arises.

For an answer see

   1) What 2 do for <...>2GXL ?

   2) What 2 do for GXL2<...> ?

Note : A demonstration of the GCF can be found in the found in the class "demo.java".