Plugins subproject? (was Re: Re: Re: [PATCH] Swixml - Extending DefaultFactory)

I believe java.net will let you setup sub-projects.  Perhaps there should
be a "plugins" or "extensions" subproject?  For example, if someone
creates a new tree tag or form tag, it'd be great to have a page listing
them for others to use and improve.  Alternative configuration extensions
or things like SWT support would also make good canidates.  Wolf should be
able to create a separate CVS module and give developers access to it w/o
affecting swixml core.  This type of thing is done in jEdit
(http://www.jedit.org) with great success.

Don

On 24 Oct 2003 [email protected] wrote:

> Well - what a conversation today....
>
> There are things that I am programming today, not just talking about it.
>
> I will be done with my core changes in a week or so and will provide them
> up the chain.
>
> I have kept backwards compatibility issues to a minimum, so if Wolf
> doesn't want to default registration through XML, he doesn't have to.
>
> The only thing that I ask is that, if you want to use an xml properties
> file, the code will be there to do so.
>
> I am sure not everyone will agree with the direction that I am going with
> my work.  I am very much trying to expand the framework of Wolf's code
> without breaking anything.  I am also trying to add features in the
> framework that I feel would lend itself to extreme flexibility.
>
> Either way, I will be done in a few weeks with the majority of changes and
> will let everyone take a look at it.
>
> I will let everyone know when I am done as well and will post the changes
> to Wolf.
>
> I am not trying to cause a rift in the group, just trying to get something
> done.
>
> Sincerely,
>
> Brian P Michael
> [email protected]
>
>
> On 10/24/2003 - 13:37:16, Don Brown said:
> > 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
> > >
> >
> >
> > _______________________________________________
> > Forum mailing list
> > [email protected]
> > http://carlsbadcubes.com/mailman/listinfo/forum_carlsbadcubes.com
> >
> >
>
>
>
>
>
> --
>