Then choice rendered getDisplayValue return just the date but the converter converts it to the right type
that the date/number converters with a locale specifies.
That would be nice yes.
The problem is that we do break api again then.. But we are on that way anyway.
johan
On 1/16/06, Johan Compagner
<[EMAIL PROTECTED]> wrote:
What do you want to convert?
The id or the display value??
The converter is used for things what a person can type and that is not the case with a drop down.
So in the dropdown world the id would need to be converted because THAT is the model object.
The display object has nothing to do with the model object it is just a visual representation.
The id generation is just there because we need to push things to the client..
But to make an example what do you expect or want to do here
I have a List of persons that has a getName() and a getId()
now i do just this
new ChoiceRenderer("name", "id")
What should the converter then do more? Should it go over the name? What should it do there?
Again Normally with all other fields a convert works on the model object and that is more or less more
the id then the display value.
Just youre statement that
"IMHO ChoiceRenderer could do better than simply using toString() to
produce a display value (see line 152). Why not utilize converters instead?"
is just not true the choice rendere doesn't use toString()
But i would love to see an example where it would really be usefull.
johanOn 1/16/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:>The renderer is just as in Swing so the renderer should return the >display value.
A Swing renderer isn't responsible to generate ids.
>Why would you go through the renderer then if you want to use the >converter for this?
The renderer currently has three responsibilities:
-It has to generate an id.
-It has to locate the value to use for displaying, e.g. you're able to select a customer but the name of the customer should be displayed.
-It has to format the display value.
But why impose the latter?
>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)
I propose to reuse converters for generating the display value ONLY. The id generation has nothing to do with formatting and is best left the way it works now.
>But i think this will be much harder to understand for people.
I find it difficult to understand that DropDownChoice and its subclasses don't use the converter infrastructure.
Imagine prices, dates or currencies in an HTML select - why aren't they formatted the same ways as in TextFields or Labels?
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
