| Newsgroups |
gmane.comp.embedded.carlsbad-cubes |
| Message-ID |
<[email protected]> |
In reply to both your previous posts Kate, as the
primary developer of the genpluginengine, I would have
to agree with Brian that it seems more viable to build
a plugin wraper with swixml (which I was actually
doing for my ui framework) that can be plugged in to
an application and used in that manner. My reply to
Brian explained one avenue that Eclipse has taken with
building a UI.
By the way, if ya'll want to use my plugin engine, I
have no objection and it has xml pull embeded, so you
would get the ability to use xmlpull "free" as it is
distributed with my gpe.jar file. Currently, gpe.jar
is 55K in size with the embeded parser. You are also
more than welcome to embed the plugin engine classes
directly into the swixml.jar so as not to need a
separate .jar for the engine itself. This will make
your swixml.jar a self contained library if you were
to convert the xml parsing to using xmlpull.
Otherwise, users still need to have a JDOM
implementation which is a separate jar. Then again,
you may be able to embed the jdom classes directly in
swixml.jar as well, saving on having to have users get
a second jar for jdom.
Anyway, I still don't see how using a plugin engine is
going to make swixml that much better. As Brian
pointed out, its an xml to Java Swing renderering
library, why pollute it with more comlexity? Keep it
simple, silly! ;) Uh, not that I am knocking my plugin
engine, it certainly is up to the task (or will be
soon enough).
--- [email protected] wrote:
> 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
>
>
> _______________________________________________
> Forum mailing list
> [email protected]
>
http://carlsbadcubes.com/mailman/listinfo/forum_carlsbadcubes.com
__________________________________
Do you Yahoo!?
Find out what made the Top Yahoo! Searches of 2003
http://search.yahoo.com/top2003