Re: Refection vs Code Generation

Kate may have seen, and I am not sure that my engine
has been decided upon to be used, but not much will
change in terms of how the engine works before it is
released. I am adding a few new features, getting the
version resolution in place and finishing up the
load/unload/reload features, but other than that I
don't plan on changing how extension points,
extensions, dependencies, and so forth are in the
plugin.xml and how they work. So if Wolf/Kate/whoever
want to start looking at using it with swixml, please
do and I'd love to be given feedback on its use. I
suspect with the yGuard obfuscation it will come in
right around 50K or so when its done, but as i said,
you are more than welcome to build the src or take the
.jar .class files and place them directly into the
swixml library so only one jar is needed.

I can see in some cases where extending the swixml
capabilities via plugins would be a great benefit, but
at the same time I am thinking that using a basic
interface structure and providing a configuration file
with basic Class.forName() calls to load dynamic
extensions might be easier to handle. I love my little
engine :D, and I know it could work well, but it may
actually be overkill for the simplicity that swixml
provides.

Fred, I am not sure I am understanding your email
though, in that swixml with reflection or code
generation? Are you saying writing strict Swing code
the "old fashioned" way? Or do you mean generating
code .class files on the fly form xml, actually
compiling them at runtime and making use of them?


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


__________________________________
Do you Yahoo!?
Yahoo! Finance Tax Center - File online. File on time.
http://taxes.yahoo.com/filing.html