Re: Enhancement to converters?

Swixml introspects all the registered classes for their constructors, 
set-, and add-methods.
In case a setter (or adder) method's parameters can be constructed by 
converting a String, the setter (or adder) is registered and can be 
called through a xml attribute. Here is an example:

	 <label text="My blue label" color="blue"/>

works, because a JLabel's setText(String s) methods takes a String 
typed parameter and Swixml provides a ColorConverter capable of 
converting a String into a java.awt.Color typed object.

Then, there is the initclass attribute, which is useful when the class 
that is represented by the tag name, could be instantiated but not with 
the default contructor. The afore mentioned example would use the 
JLabels default constructor to get an instance. The following example, 
taken form the Swixml sample page at http://www.swixml.org/samples/

	<combobox initclass="ComboModel"  Action="DO_SELECT"  />

instantiates a JComboBox class by using the constructor that takes a 
ComboBoxModel parameter:
JComboBox(ComboBoxModel aModel)

( .. More on how to use the initclass parameter can be found here:
http://swixml.carlsbadcubes.com/userguide/html/attr/initclass.html )

The limitation of the initclass can be summarized with:
The initclass implementation needs to provide a default constructor or 
a constructor with just a String argument. Alternatively, a 
getInstance() method (with no argument) may be implemented, returning 
an initclass  instance.


If you have used Swixml at all,  everything up to this point should 
have been working knowledge ;-)

The problem some of us currently facing is the limited support for 
available setter methods, i.e. setCellRenderer()
<list cellrenderer="whatever"/> is currently not supported, because the 
JList's setCellRenderer() methods requires an instance of CellRenderer 
and there is no converter covering for this case.

Like Frank mentioned in a previous post, one could image to handle this 
with by adding a converter that would convert a classname into an 
object (instance of that class). However, one can easily find cases 
where a default constructor doesn't exist or is not what's required.

A possible solution to this problem would be to elevate delegates from 
attributes to tags. To give an example:
Instead of

<list id="alist" cellrenderer="com.mydomain.MyCellRenderer"/>

a nested tag would be used:

<list id="alist">
	<mycellrenderer>
</list>

Since renders are often re-used, the already know refid attribute could 
help to define this case:

<list id="alist">
	<mycellrenderer id="renderer123"/>
</list>

<list id="alist">
	<mycellrenderer refid="renderer123"/>
</list>

Elevating delegates to tag would also allow to initialize it since we 
could provide the full parser support, allowing to use setter and the 
initclass attribute as well.

Since we probably don't want to allow to instantiate every class know 
to the system, delegates would have to be registered (like tags and 
converters are being registered.) A simple map could take care of this. 
This would also allow for not having to flag a delegate tag.
If a tag is found registered it's representing class is instantiated 
and added into the parent - else we would try to find it in the 
delegate map.
If found, we instantiate it, set it up and try to find a setter in the 
parent.

Wolf