Re: Re: [PATCH] Swixml - Extending DefaultFactory

On Fri, 24 Oct 2003, kate rhodes wrote:
<snip />
> 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.

Good point re configurability.  Perhaps the swixml could host "plugins" or
swixml extensions?  For the Struts (http://jakarta.apache.org/struts)
project, we keep the core very clean (well, try to anyways :) but opened
up a sourceforge project (http://struts.sf.net) to host Struts extensions
and plugins to encourage developers to try new things with Struts.  Many
popular projects, like Tiles and the Validator, ended up in Struts later
due to user popularity.  The nice things about the sf site are it is
much easier to get other devs involved, gave their plugins more visibility, and
the user community can weed out the extensions that aren't as useful.

As it is, I am very happy with the state of swixml extensibility.  The tag
concept is great.  My only requests are for the aforementioned factory
refactoring, and a way to override action and variable linking behavior.

Don

>
>
> 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
> >
> >
>
>
>
> _______________________________________________
> Forum mailing list
> [email protected]
> http://carlsbadcubes.com/mailman/listinfo/forum_carlsbadcubes.com
>