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
>
>
--
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.