A couple of days ago I had posted a suggestion about adding delegates
into Swixml.
Since it was posted somewhere deep inside another thread, not everyone
might have read it.
Here we go again:
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 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.
