Kate,
I partially agree and partially don't agree to your last email.
1) I do agree that we are talking about the future architecture of
Swixml.
2) I agree that JDOM is easy to work with and SAX/XML Pull could
complicate the architecture overall.
3) I don't agree with the forum on the need for SwixML to "become" a
plug-in framework
of it's own.
Why would you ever want to create SwiXML as a "plugin framework"?
Swixml is an XML to Java generation tool. (XUL)
This is something that should be plugged into a "plugin"
framework.
In my belief, Swixml, shouldn't ever need to become a framework that
supports plug-ins.
It should be an XML to Java Parser.
I do believe, Swixml should be integrated into any number of existing
frameworks, like Eclipse, or something like that.
4) Secondly, I would like to have any application that I create,
utilize a minimum number of XML files.
The first file, would have the splash screen, and minimum set of
widgets.
I then will parse the first file.
Second, I will have a main XML file with most of widgets for the bulk
of the application
that will be used frequently.
Third, I will have a number of files that contain specialized widgets,
panels, etc, that are
called in-frequently (or called in separate threads).
So, I do feel, that my files will get quite large.
5) The issue, of whether Swixml becomes more than just Swing DEFINES
how far the architecture
must move to support the goals.
If, Swixml will support other tags, non-swixml and non-SWT, such as
Jelly, Luxor, XUL, etc.
then the issue of whether XML Pull, SAX or JDOM is better will need to
be truely addressed.
6) I am almost ready to send my version 2.0 candidate code to everyone.
I have put over 3 months of time and many hours into refactoring
version 128 of the code. This refactoring
allows much code reuse to support SWT but stops short of introducting
namespaces.
As I have truely worked with Swixml, and have touched/refactored
nearly every portion
of the code, I have found that the current architecture is limited.
Currently, any Java Bean can be associated with the current
architecture and used just using the register tag.
But advanced namespace processing, like in Jelly, would not work in
the current architecture.
That is where a change in the architecture towards, XML Pull or SAX
could be beneficial.
The current architecture doesn't know how to process specialized,
non-Swing, non-bean, classes.
(Yes, I know you could create a bean class to do it, but you would
have to change
the code if you needed parent/child processing like swing).
The current architecture also doesn't know how to parse different
"hierarchies" of tags, like Jelly.
??) Could JDOM work with a more advanced architecture, namespaces and
different parsers??
Yes.
Could XML Pull or SAX work better?
Yes, but the architecture would need to shift pretty substantially to
accommodate.
Again, just my 2.5 cents.
Brian
