| Newsgroups |
gmane.comp.embedded.carlsbad-cubes |
| Message-ID |
<[email protected]> |
as for plug-in engine the following has been suggested and so far no
one else has come up with a better proposition. I know some of the
developers on this project and it's definitely ins a good working state
and has continued development.
http://genpluginengine.sourceforge.net/
-Kate
On Jan 4, 2004, at 4:36 PM, [email protected] wrote:
> 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
>
>
> _______________________________________________
> Forum mailing list
> [email protected]
> http://carlsbadcubes.com/mailman/listinfo/forum_carlsbadcubes.com