| Newsgroups |
gmane.comp.embedded.carlsbad-cubes |
| Message-ID |
<[email protected]> |
Brian,
The one thing I don't see swixml being useful for is a
pluggable architecture like Eclipse or my own. I say
this with not a lot of experience with swixml, so
perhaps I am wrong. But the way Eclipse works, each
plugin provides a piece of the UI within it's
plugin.xml descriptor, but not like how swixml would
expect. Core plugins to eclipse provide a number of
extension points, each defining an xml schema that is
expected of any plugin wishing to extend it. Each
plugin to extend it must provide a validated bit of
xml interwoven within the <extension point/> node
inside the plugin.xml. For example, to add a menu, you
extend the actionSet and provide a menu name, action
class, etc. The benefit to this design is that the
entire UI is built/rendered, but not a bit of plugin
code is created until a menu item or button is clicked
to trigger the plugin's creation. You can literarlly
load hundreds of plugins, building a pretty complex UI
and very little overhead in object creation, other
than the swing elements.
Unless I misunderstood Kate (when she slammed me for
being a beginner :D ) my understanding is that swixml
is not able to build a full ui from various pieces of
xml each parsed at different times, including the
ability at runtime to parse and apply a bit of xml
into a Swing component, add it and update the screen.
In my plugin engine, in Eclipse, and in some others,
dynamically loading, unloading and reloading of
plugins is possible, and a UI needs to be able to
remove and/or add UI componenets at any point within
the application lifecycle.
I wish ya'll would give some examples or reasons why
you think xmlpull is so complicated and would
convolute the architecture. I still find working with
direct String comparisons much easier than working
with Document elements and such.
--- [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
__________________________________
Do you Yahoo!?
Find out what made the Top Yahoo! Searches of 2003
http://search.yahoo.com/top2003