The renderer is just as in Swing so the renderer should return the display value.
That is what it does say in its name.
Why would you go through the renderer then if you want to use the converter for this?
convert(choice);
would be then what you would use.
And the convert method can then call the ChoiceRenderer OR the converter or something like that.
The problem is then that the display value is easy. converter.convert(choice, String.class)
but the id value how is that again got from it then we need a class type so that we can do converter.convert(choice,Int.class)
But i think this will be much harder to understand for people.
johan
On 1/15/06, Sven Meier <[EMAIL PROTECTED]> wrote:
Globally registered converters are a great way to format values
consistently throughout an application.
But regretfully these converters are not used to format choices of a
DropDownChoice. Setting a custom converter explicitly on the
DropDownChoice doesn't help either.
IMHO ChoiceRenderer could do better than simply using toString() to
produce a display value (see line 152). Why not utilize converters instead?
We could change IChoiceRenderer#getDisplayValue(Object) to return Object
instead of a String:
/**
* Get the value for displaying to an end user.
*
* @param object
* the actual object
* @return the value meant for displaying to an end user
*/
Object getDisplayValue(Object object);
Then converting a choice value to a String can be left to AbstractChoice
(line 319 and similar in subclasses):
protected void appendOptionHtml(StringBuffer buffer, Object choice,
int index)
{
final String displayValue =
convert(renderer.getDisplayValue(choice));
...
}
If we split Component#getModelObjectAsString() into two methods we can
reuse the converting functionality and get escaping for free:
/**
* Gets a model object as a string.
*
* @return Model object for this component as a string
*/
public final String getModelObjectAsString()
{
final Object modelObject = getModelObject();
return convert(modelObject);
}
/**
* Convert the given object into a string.
*
* @param value
* The value to convert
* @return The converted value
*/
protected final String convert(Object object)
{
if (object != null)
{
// Get converter
final IConverter converter = getConverter();
// Model string from property
final String modelString = (String)converter.convert(object,
String.class);
// If we should escape the markup
if (getFlag(FLAG_ESCAPE_MODEL_STRINGS))
{
// Escape it
return Strings.escapeMarkup(modelString);
}
return modelString;
}
return "";
}
Of course custom IChoiceRenderers can continue to format the value by
themself. But in most cases the IChoiceRenderer will only be responsible
to locate the displayed value, formatting is delegated to converters.
What do you think? I could send in a patch but wanted to hear your
opinion on this first.
Sven
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
