I wanted to get back with you regarding your questions about SAX.
I decided to pause my efforts and take an in-depth look at Jelly.
To describe SAX parsing, SAX uses a parse for each of the following:
Begin Document
Begin Tag
End Tag
Begin CDATA
End CDATA
End Document
and some others, but that will do for this explanation.
Jelly uses SAX to parse it's documents. I describe this parse as a two-pass parse.
The first pass, Jelly uses SAX to create an event pipeline, parsing the
document as it goes. During this pass, Jelly builds a tree of all TAGs using their "Tag" class.
This class tree, stores all the pertinent information necessary to instantiate java classes, including information about
parent/child relationships and element hierarchies.
At this stage, the XML Document has been read, parsed and processed.
The second phase of the two-pass parse, then reads the TAG Tree and
instantiates the java classes associated with tag.
So to parse the following (Taken from the Accelerator.xml sample):
<frame name="mainframe" size="640,480" title="S W I X M L" plaf="com.sun.java.swing.plaf.windows.WindowsLookAndFeel">
<menubar name="menubar">
<menu name="filemenu" text="File">
<menuitem name="mi_new" text="New" icon="samples/icons/new.gif" mnemonic="VK_N" accelerator="control N" Action="newAction"/>
<menuitem name="mi_open" text="Open" icon="samples/icons/open.gif" mnemonic="VK_O" Accelerator="control O" ActionCommand="open"/>
<menuitem name="mi_save" text="Save" icon="samples/icons/save.gif" mnemonic="VK_S" ActionCommand="save"/>
<separator/>
<menuitem name="mi_exit" text="Exit" icon="samples/icons/exit.gif" mnemonic="VK_X" Accelerator="control X" ActionCommand="exit"/>
</menu>
<menu text="Help">
<menuitem name="mi_about" text="About" enabled="true" icon="samples/icons/info.gif" Accelerator="alt A" Action="aboutAction" />
</menu>
</menubar>
1) Jelly uses SAX to parse each tag
a) SAX parses the begin document
b) SAX sees the beginning of a new tag, <frame>
It then Parses the <frame> tag, instantiating a new Tag object for the frame tag.
c) SAX then sees the beginning of the new tag, parses the <menubar> tag
It Parses the <menubar> tag, instantiating a new Tag object for the <menubar> tag
d) SAX then sees the beginning of the <menu> tag
etc, etc
e) SAX then sees the end tag of <menuitem>,.....
etc.
etc
etc
e) SAX parses the end document
2) Parse continues using the begin tag, end tag scenario.
3) Jelly then runs through the tree of newly created objects and "compiles" it.
As it runs through the compile, it then parses the tree, building and instantiating
the swing objects as it runs the compile.
For standard Java Beans, with standard getter and setters, a "DynaBean" tag was created in phase 1.
The real object is then instantiated.
For all other objects, a "DoTag" method on the parser of that object is called.
This "DoTag" is then called and runs the appropriate code to build the object, add children, etc.
In Jelly, the parsing of the document goes very quickly. Much faster than our current SwiXML.
During the second phase of parsing/compiling, Jelly executes basically everything Swixml executes during Swixml's first and only pass.
So, the second pass takes time.
I haven't actually taken statistics on the timing, but pass 1 goes really quick. Pass 2 is where most of the
work is performed.
Now considering, Jelly is now parsing an in-memory Tag Tree, similar to parsing the XML Document, I have to
believe that the time it takes would be similar to the single pass of Swixml.
Swixml uses a single pass parse, only limited in version 1 to Swing objects where jelly can parse many, many different types of objects (loggers, swing, swt, etc)
There is about 30 or so entire Jelly libraries of different types of tags.
For Swixml to use SAX, a fairly complete and complex Event Pipeline would have to be built that would eliminate the concept of a two-pass parse.
The problem, essentially, is in maintaining the deep parent/child relationships inherent in Swing/SWT and any object heirarchy.
So, net/net, is there benefit, long term in moving Swixml to use SAX?
I have now worked with the Swixml internals of the parser for Version 2.0 and believe that if SwiXML were to grow beyond Swing Only,
then the use of SAX might be beneficial. It would simplify the complexity of the architecture and lend itself to creating
namespaces, non-swing objects such as logging, data, etc.
So for all it is worth, Happy New Year!
Sincerely,
Brian P Michael
630-897-8364 x17
[EMAIL PROTECTED]
BEGIN:VCARD VERSION:2.1 N:Michael;Brian;P FN:Brian P Michael ORG:GoldParrot Corporation TITLE:President TEL;WORK;VOICE:630-897-8364 x17 TEL;WORK;FAX:630-897-8364 x21 ADR;WORK:;;1326 Eastwood Dr;Aurora;IL;60506;USA LABEL;WORK;ENCODING=QUOTED-PRINTABLE:1326 Eastwood Dr=0D=0AAurora, IL 60506=0D=0AUSA EMAIL;PREF;INTERNET:[EMAIL PROTECTED] REV:20020311T030256Z END:VCARD
