Re: Enhancement to converters?

Kate Rhodes wrote:
> Actually, by doing this you've just saved me a bunch of time because I 
> will be hitting that problem shortly... Still writing the custom renderer.
> 
> Thoughts:
> cellrenderer="fieldOfCallingClass"  seems like the best way to do it 
> since that's the way actions and everything else works.

Hm, I usually don't need the renderer in the calling class. Bluntly 
speaking, I do not need the renderer as attribute of *any* class at all. 
Usually (but this may as well be only my personal approach) I re-use the 
renderer if possible. This may save some memory footprint if a lot of 
(e.g.) tables are used with the same renderer all over.

> cellrenderer="fullQualifiedClassNameForRendererClass"  seems acceptable 
> in use but it kinda breaks the standard usage so I'm not too fond of the 
> idea. I think it's ok in initclass because that's specifically for 
> initializing a class.

I do not like the renderer being a initclass argument. This will IMHO 
easily create confusion (because the name implies the initialization of 
the element "initclass" is a atttribute from -- but the renderer has 
absolutly nothing to do with initialization of the element, only with 
its visual realization).

> 
> Question: how often do renderers take arguments in their constructors? I 
> haven't encountered it yet but I don't think that means much.

Um, all the renderers I wrote did not take any argument in their 
constructors. Because renderers are a mere visual thing, they should 
fetch icons or the like from configuration files or the like...


> so yeah IMNSHO that work is useful, I'll happily be a guinea pig if you 
> want one.

Happy to have someone agreeing with me :)

The actual code needs polishing, though. The current solution is not 
that good in design and I would like to get this clean.

One alternative to my current solution is to change the 
Converter.convert(Class, Attribute, Localizer) completly to
Converter.convert(Class, Attribute, SwingEngine)

Of course, all converter must be changed accordingly to use 
engine.getLocalizer() instead of the localizer from the argument. This 
may be solved through an abstract class implementing the "new" convert:
public Object convert(Class c, Attribute a, SwingEngine e) {
   convert(c, a, e.getLocalizer());
}
public abstract Object convert(Class c, Attribute a, Localizer l);

This is IMHO the best solution and enables all possible implementations 
of converters without to much work on existing ones.

Wolf, how do you want to get the code? Do I have (or could get) write 
access to the CVS repository? I do not know how the development is 
currently done (branches for stuff like this, whatever)

Yours,

Frank

> 
> -Kate
> 
> Quoting Frank Meißner <[email protected]>:
> 
> 
>>Hello there,
>>
>>I recently got in the GUI buisiness again and I'm glad to write some 
>>swixml code again :).
>>
>>During this, I stumbled across a little problem: I would like to use a 
>>custom renderer to one of my lists. I'm aware of the procedure swixml 
>>gets access to the attributes of the created objects. In short, if there 
>>is a setxxxx-method for a given GUI object, one might use the 
>>xxxx-attribute in ones xml GUI description file. But as far as I 
>>understand the mechanism in org.swixml.Parser, this is of no use for 
>>renderers at all: I'm not able to use cellrenderer="fieldOfCallingClass" 
>>(to have the cell-renderer assigned from a field in the class calling 
>>swingEngine.render(...) nor 
>>cellrenderer="fullQualifiedClassNameForRendererClass" (to have the cell 
>>renderer created using the FQN of the cell renderer class).
>>
>>First I tried to write a Converter for this. This may work for the 
>>second case (the cellrenderer-attribute tells the classname to create an 
>>object from) but not the first case. So I wrote my own converter 
>>interface (EnhancedConverter) and changed the call to convert(Class, 
>>Attribute, Localizer) in the Parser class to convert(Class, Attribute, 
>>SwingEngine) if the converter is a EnhancedConverter. By getting access 
>>to the actual SwingEngine, the convert-method is able to fetch attribute 
>>values from the calling class. If there is need to access the Localizer, 
>>just use swingEngine.getLocalizer()...
>>
>>Of course I'm able to write my own tag and thus implementing the access 
>>to the cell renderer. But IMHO cell renderers are pure GUI related 
>>things and usually they are created using the standard constructor. So 
>>(first), why bother in the program *which* cell renderer to use? Second, 
>>the current behaviour of setCellRenderer is of no practical use, is'nt 
>>it? Third, there is no workaround like the use of initclass (because 
>>there is neither no Jxxxx (xxxx: one of List,Table,Tree,...) with a 
>>*renderer* as argument...)
>>
>>Please tell me what you think about the problem and if someone is 
>>interested in the enhancements I made. Or tell me I wasted my time and 
>>should go and write my own custom tag for this nifty problem :-/
>>
>>Yours,
>>
>>Frank
>>
>>-- 
>>AuthentiDate International AG
>>Großenbaumer Weg 6
>>40472 Düsseldorf / Germany
>>Phone : +49(0)211 43 69 89-52
>>FAX : +49(0)211 43 69 89-19
>>
>>Erfahren Sie mehr unter:
>>www.authentidate.de
>>
>>Oder beim
>>Enterprise Signature Day
>>11. März 2004, Düsseldorf
>>www.enterprise-signature-day.de
>>
>>
>>
>>
>>
>>_______________________________________________
>>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
> 


-- 
AuthentiDate International AG
Großenbaumer Weg 6
40472 Düsseldorf / Germany
Phone : +49(0)211 43 69 89-52
FAX : +49(0)211 43 69 89-19

Erfahren Sie mehr unter:
www.authentidate.de

Oder beim
Enterprise Signature Day
11. März 2004, Düsseldorf
www.enterprise-signature-day.de