Re: Enhancement to converters?

Hi Frank,
Good idea! I think I do something in the line you are describing in the 
work I'm doing on Franklin, the Swixml GUI Editor.
I could move that into Swixml - there is actually a lot of stuff I'm no 
sure of where it eventually end up, in Swixml or Franklin.
Anyway, I definitely would like to see your code.

If I remember correctly, I still put all the class names that I want to 
allow to be loaded and instanced that way in a collection. But hey - 
you are the security expert ;-)

On another topic, I had to look at Governikus, Oscar, OSCI.de etc, 
today. Is that stuff any good?

	Wolf Paulus

C a r l s b a d   C u b e s
mailto:[email protected]

CONFIDENTIALITY NOTICE:
This message is intended only for the use of the individual or entity 
to which it is addressed, and may contain information that is 
privileged, confidential and exempt from disclosure under applicable 
law.
If you are not the intended recipient, please contact the sender by 
reply email and destroy all copies of the original message.
On Mar 3, 2004, at 7:33 AM, Frank Meißner wrote:

> 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