Fred,
The point you make is well known and widely understood.
XUL attributes are just text and have to be de-serialized into objects.
Swixml is trying to do this with the converter classes.
For your color example please check here:
http://www.swixml.org/apidocs/org/swixml/converters/ColorConverter.html
Wolf
On Mar 30, 2004, at 9:39 AM, Kate Rhodes wrote:
I agree about extending attributes needing to be more obvious. I think
this is mostly a documentation issue although I haven't actually tried
it.
The biggest problem with things like new Color(xxx, xxx, xxx) as an
attribute value is that there are just too many possibilities that
people would want and too little time to code them all. I think the
best approach is to do the main ones (see below) and just really
document how to extend it. Plus get this all the things like this into
a plug-in archictecture (old discussion see archives) so that we can
all contribute our little bits to the whole.
While Color.WHITE may not work I *think* that WHITE does. I think all
the Color.xxx have been implemented. But, it's been a while since I
tried that I just remember it working and not having to specify hex
vals.
-Kate
[EMAIL PROTECTED] wrote:
I've changed the Subject line in this reply to reflect the new topic.
This was formerly about JPanel graphics.
There are certainly cases where the dynamic (runtime) construction of
a GUI using refection, as Swixml currently does, is necessary. Kate
gave an example, and I'm sure there are plenty of others.
One question is whether there are also advantages to generating code,
other than a little execution time saved at runtime, which doesn't
seem to be much of a problem for most users.
A serious deficiency of the current reflection approach is that the
values of the attributes are seriously limited. For example, to
specify the background color of my JPanel, I would like to be able to
used attributes like
background="Color.WHITE"
background="new Color(45, 200, 255)"
background="new Color(0xFFAAAA)"
None of these work with Swixml, and it's hard to see how to make some
of them work, or even worse, calls to get system colors. [By the
way, what Swixml does allow is background="FFAAAA".] I see this as
one of the serious weaknesses of Swixml as more and more work must be
put into attribute conversions.
Simple text substitution could be used to map most attributes of the
form
xxx="yyy"
into Java code like
comp.setXxx(yyy);
This provides features that Swixml can't. So the code generation
approach is not simply a subset of the reflection approach - it has
its own strengths.
At my early learning stage I haven't used many of Swixml's features,
so perhaps my simple static GUIs haven't given me enuf appreciation
of its reflective capabilities to overcome the constant pain of
attribute value hassles. At this point I'm leaning toward the
advantages of code generation, but will continue to try out new
features of Swixml in the expectation of finding more goodies.
-- Fred
Frank Meissner writes:
Hello Fred,
[EMAIL PROTECTED] wrote:
Hi Frank,
Regarding your offtopic-subject: There is always the tradeoff
between flexibility and performance. The changes you suggest
improve neither. Please do'nt be offended, though...
It would certainly seem that removing the XML
interpretation/reflection layer should improve performance -- not
that I have any complaints about Swixml performance, which I think
is quite satisfactory. Because you don't agree on something that
seems obvous, we're probably working with different assumptions.
Maybe I'll find some time in the future to create an example of
what I mean.
Oops, I did not make myself clear here. Removing the
reflection/interpreation part *would* improve performance, agreed.
I meant the changes you originally suggested. BTW: I thought about
removing some reflection code myself (replacing it with generated
code), leaving reflection as "last resort" ;)
And I'm certainly not offended by disagreements with constructive
intent -- hope you feel similarly.
Glad to hear :)
Frank
-- Fred
_______________________________________________
Forum mailing list
Forum@carlsbadcubes.com
http://carlsbadcubes.com/mailman/listinfo/forum_carlsbadcubes.com
_______________________________________________
Forum mailing list
Forum@carlsbadcubes.com
http://carlsbadcubes.com/mailman/listinfo/forum_carlsbadcubes.com
_______________________________________________
Forum mailing list
Forum@carlsbadcubes.com
http://carlsbadcubes.com/mailman/listinfo/forum_carlsbadcubes.com
_______________________________________________
Forum mailing list
Forum@carlsbadcubes.com
http://carlsbadcubes.com/mailman/listinfo/forum_carlsbadcubes.com
