Re: Refection vs Code Generation

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
>
>