Re: Refection vs Code Generation

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