Re: Refection vs Code Generation

Hello again,

I do not want to generate the whole xml file into whatever java code.
The intention I had in mind was replacing some of the things swixml does
by reflection to be done by generated code. There would be no change to
the user of swixml (means: the developer) except a slightly bigger
jar-file of course.

The approach to have the GUI in xml -- and *only* in XML (except on the
screen) -- is the main thing I choose swixml. It allows subtle changes
by a user (of your application), easily branding, customer-related GUI
files and the like. No hassle about needing java-, class- or jar-files
to remember and have handy for customer care.

Regarding the aspect of attribute values: This is IMHO a merily
Converter specific issue. (Wolf, correct me if I'm wrong on this). So,
go ahead, tune the converters! I agree with kate this is a docu issue...

Frank

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