| Newsgroups |
gmane.comp.embedded.carlsbad-cubes |
| Message-ID |
<[email protected]> |
ok, this has been discussed a lot here, so for more details check the
archives.
the summary is this
Swixml only supports Swing objects instantiation and setting of a few
variables it does not allow you to, for example define the contents of
a JComboBox or a JTable.
There are Many of us who wish to be able to do this with Swixml however
it is Wolf's wish to keep that out of the core, and he's got some good
reasons.
Now, with that in mind the plug-ins are used as extensions to the
processing of the XML. so obviously JDOM would be a serious advantage
here. Also, keeping the parsed XML in memory after parsing would be a
real waste of resources so a plug in after processing would not be a
great idea. although I can see the argument for one and have the system
notify the SwingEngine when postprocessing is done so that the doc
could be garbage collected.
Why a plug in framework? because forking the code would be dumb to
support things like that and doing it without a plug in framework could
result in some conflicting classes being released by people and the
inability to combine the contributions of different developers. If we
add an extension point (or points) to Swixml then you can just drop in
the added functionality you want. And it's not just a matter of
defining things like the contens of comboboxes. Imagine you have a
complex widget that you use in many places.. you can define a plug in
that parses some small custom XML to generate that complex widget...
(say, a tree with each node being a network device with icons for each
one) instead of having to write java every single time you want that
somewhere.
"The issue, of whether Swixml becomes more than just Swing DEFINES how
far the architecture
must move to support the goals."
That issue has already been discussed repeatedly.. .Swixml will NOT go
beyond swing. Yes many people want that, but it is not the goal of the
Swixml project to do that. Jelly handles this just fine. Two of
Swixml's greatest virtues are it's simplicity and its focused purpose.
Wolf doesn't want swixml to go beyond Swing. Yes many of it's users do,
and that's fine... if we have a plug-in architecture they can do that
without altering the core.
"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."
It won't support them. See above and the archives.
I applaud your efforts to make it support SWT, I think that's great,
and there's definitely a demand for it. But Wolf has made it abundantly
clear that Swixml will only support Swing. It sounds to me like you
may have a good reason to fork development into a new project.
Obviously don't just take my word for it. Talk to him first. I'd hate
to see the project forked just because I was mistaken here.
While we're on the topic of what won't be in Swixml: Swixml is really
trying to avoid any functional directives in the XML. If you want that
Jelly is the place to be. It support that, Swing, SWT, and maybe more.
Wolf, please holler if I've misrepresented your views here.
-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