Re: Re: [PATCH] Swixml - Extending DefaultFactory

Personally I don't care to much about supporting SWT. I think it would 
be cool and if it was available I would use it but I'm ok without it.  
With that said however I, and I think a good number of others, want to 
use SWIXML to do things that you don't want SWIXML to do, like, populate 
tables or combo-boxes. This would save me so much coding. I'm fine with 
the fact that you don't want to do it but making SWIXML extendable 
significantly enhances it's value to the community. It lets it grow as a 
tool in ways its creators can't guess at. And The beauty of this is that 
you don't HAVE to use any of the extra stuff... if you want a simple 
core just use it straight out of the box.


But me, I'd use the extended version because I can use XSL to transform 
my data into guis without a bare minimum of compiled code. Just 
imagine... you could embed dynamically generated graphs in your apps by 
defining a new set of tags that hooked into jFreeChart.  Hook it into 
sebversions XML logs and you have a graph of code check ins for your 
company, all sorts of goodness.


-Kate

Wolf Paulus wrote:

>>From what I have seen and learned so far I'm not really in favor of
>registering Tags by parsing XML documents. While this would probably be a
>one time hit, parsing still takes time and we should only add to the already
>long startup time where this is absolutely necessary.
>
>Besides a potential performance issue, I don't see what we gain. In a recent
>project, we registered about 10 custom Swixml tags, some new and some were
>just overwriting/replacing the default tags. All this happens dynamically at
>runtime. The implementation of a XYZ tag may change with every instantiation
>of a SwingEngine class - every time a dialog i.e. is rendered.
>
>
>
>I understand that this request is mostly driven by the need to support SWT
>along side JFC - to be clear, I support those efforts and Swixml 2.0 design
>will be enabling and/ or supporting SWT - however, I don't want to replace
>Java with XML and this stuff definitively goes into this direction.
>
><tag name="Applet" factory="javax.swing.JApplet" />
>
>To me, this looks like then indrodution of a script language into Swixml,
>which is not very likely to succeed. Swixml was always thought to be plain,
>simple, small, and fast.
>
>This is not Mozilla XUL nor Luxor.
>
>Wolf
>  
>