RE: Swixml and SAX, Jelly

I looked at Jelly too, as they have several projects that are similiar to
this one and have, from what I understand, a strong XML framework for
processing markup.  However, all that framework takes processing,
third-party jars, and resources.  What I like about swix is how simple and
small it is.  Yes, you can't use it to easily to create other objects, but
by focusing on simply creating Swing (and perhaps other GUI frameworks)
elements, you get speed, simplicity, and low resource usage.

That said, I think a move to SAX would be perfect for swixml.  Not only
does that remove the JDOM jar requirement, but SAX is tons faster and
uses way less resources.  To implement SAX in swixml, I would probably try
to avoid creating an XML event pipeline if I could help it.  Yes, they are
very powerful and flexible (in fact, I'm using them in several other
projects), but I think this project doesn't need their overhead.
Furthermore, by not creating an object tree modeling the XML, either of
JDOM objects or Tag objects, we are using much less resources and doing
less processing.

Would a move to SAX result in more parsing code? Absolutely, and in fact,
the code would probably get a little harder to follow, however, I think
the benefits far outwiegh the costs.  Look at how far thinlet has gotten
and it's all in one class! :)  (not that I'm suggesting that of course)

By moving to SAX, swixml would be stream-based, generating objects as it
parses, rather than waiting till a xml object tree is created first.
There are a couple of features of swixml, xincludes and attribute
copying, that we'd have to work around, but I think it is still
doable.

Don

On Mon, 29 Dec 2003, Brian P Michael wrote:

> Don,
>
> 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]
>
>
>