It could be left as is and use the display value as expected (i.e.
<input type="checkbox" id="ID_VALUE" value="DISPLAY_VALUE" />).
Another option would be to have an identifier renderer:
public interface IChoiceRenderer extends IIdentifierRenderer
{
Object getDisplayValue(Object object);
}
public interface IIdentifierRenderer extends IClusterable
{
String getIdValue(Object object, int index);
}
-----Original Message-----
From: Igor Vaynberg [mailto:[EMAIL PROTECTED]
Sent: Friday, May 16, 2008 11:47 AM
To: users@wicket.apache.org
Subject: Re: IChoiceRenderer: RadioGroup CheckBoxMultipleChoice
if you use an ldm in choice/choicegroup then you should have instance
equality available since you will probably load the objects from the
same place, so during request processing they are consistent.
as far as choicerenderer, i dont think thats a good idea, what do you do
with getdisplayvalue()?
-igor
On Fri, May 16, 2008 at 8:35 AM, Hoover, William <[EMAIL PROTECTED]>
wrote:
> I agree, but there are some cases where it will not be possible to
> implement equals/hashcode on the model object.
>
> I would be more of a proponent to have as much consistency across
> components as possible- which would mean that ICoiceRenderer would be
> available, but not enforced, in any component that needs to handle
> choices (this is already the case for models ---> IModelComparator
> Component#getModelComparator(...)).
>
> I'm not sure I understand what you mean by using a
> LoadableDetachableModel to solve the issue. Could you elaborate?
>
> -----Original Message-----
> From: Igor Vaynberg [mailto:[EMAIL PROTECTED]
> Sent: Friday, May 16, 2008 11:12 AM
> To: users@wicket.apache.org
> Subject: Re: IChoiceRenderer: RadioGroup CheckBoxMultipleChoice
>
> then use loadable detachable models that will ensure instance
equality.
> we can let the group take a comparator, but its yet another
> complication. i see it as a reasonable enough requirement that objects
> properly implement equals and hashcode.
>
> -igor
>
> On Fri, May 16, 2008 at 7:58 AM, Hoover, William <[EMAIL PROTECTED]>
> wrote:
>> yes, that will work in my example, but what if MyObjectOption is not
>> part of my namespace?
>>
>> -----Original Message-----
>> From: Igor Vaynberg [mailto:[EMAIL PROTECTED]
>> Sent: Friday, May 16, 2008 10:14 AM
>> To: users@wicket.apache.org
>> Subject: Re: IChoiceRenderer: RadioGroup CheckBoxMultipleChoice
>>
>> why dont you just implement equals/hashcode on MyObjectOption???
>>
>> -igor
>>
>>
>> On Fri, May 16, 2008 at 5:14 AM, Hoover, William
>> <[EMAIL PROTECTED]>
>> wrote:
>>> Here is an example of what I'm referring to:
>>>
>>> class MyObject {
>>> private Long id;
>>> private MyObjectOption myObjectOption;
>>>
>>> public MyObject(final Long id){
>>> setId(id);
>>> ...
>>> }
>>> ...
>>> }
>>>
>>> class MyObjectOption {
>>> private Long id;
>>> private String name;
>>>
>>> public MyObjectOption(final Long id){
>>> setId(id);
>>> ...
>>> }
>>> ...
>>> }
>>>
>>> // in the WebPage
>>> final MyObject myObject = new MyObject(1L); ...
>>> myObject.setMyObjectOption(new MyObjectOption(200L));
>>>
>>> final List<MyObjectOption> myObjectOptionList = new
>>> ArrayList<MyObjectOption>(); myObjectOptionList.add(new
>>> MyObjectOption(100L)); myObjectOptionList.add(new
>>> MyObjectOption(200L)); myObjectOptionList.add(new
>>> MyObjectOption(300L));
>>>
>>> final Form myForm = new Form("form-myobject", new
>>> CompoundPropertyModel(myObject)); ...
>>> final RadioGroup group = new RadioGroup("myObjectOption");
>>> group.add(new ListView("div-myobject-options-view", myObjectList) {
>>> protected final void populateItem(final ListItem item) {
>>> final MyObjectOption myObjectOption =
>>> (MyObjectOption)
>
>>> item.getModelObject();
>>> item.add(new Label("label-myobject-option-name",
>>> myObjectOption.getName()));
>>> item.add(new Radio("input-radio-myobject-option", new
>>> Model(myObjectOption)));
>>> }
>>> });
>>> myForm.add(group);
>>> add(myForm);
>>>
>>>
>>> <form wicket:id="form-myobject">
>>> <div wicket:id="myObjectOption">
>>> <div wicket:id="div-myobject-options-view">
>>> <label
wicket:id="label-myobject-option-name">
>>> [MyObjectOption Name]
>>> </label>
>>> <input
wicket:id="input-radio-myobject-option"
>>> type="radio" />
>>> </div>
>>> </div>
>>> </form>
>>>
>>> In the example above myObjectOption would never be selected because
>>> it
>>
>>> is not the same instance of the MyObjectOption that is in
>>> myObjectOptionList (index 1) even though they share the same ID. If
>>> an
>>
>>> IChoiceRenderer was provided to the RadioGroup the following could
>>> accomplish the task of making the selection work:
>>>
>>> final IChoiceRenderer myObjectOptionRenderer = new ChoiceRenderer()
{
>>> ...
>>> public final String getIdValue(final Object object, final int
>>> index) {
>>> final Object id = ((MyObjectOption) object).getId();
>>> return (id != null) ? id.toString() :
>>> super.getIdValue(object, index);
>>> }
>>> ...
>>> };
>>>
>>> -----Original Message-----
>>> From: Igor Vaynberg [mailto:[EMAIL PROTECTED]
>>> Sent: Thursday, May 15, 2008 7:16 PM
>>> To: users@wicket.apache.org
>>> Subject: Re: IChoiceRenderer: RadioGroup CheckBoxMultipleChoice
>>>
>>> On Thu, May 15, 2008 at 3:12 PM, Hoover, William
>>> <[EMAIL PROTECTED]>
>>> wrote:
>>>> It's strange that that kind of functionality is provided when
>>>> multiple
>>>
>>>> selections is needed (i.e. CheckBoxMultipleChoice), but it is not
>>>> when
>>>
>>>> only one choice is needed (i.e. RadioGroup/CheckGroup).
>>>
>>> CheckGroup is a muti-selection component
>>>
>>>
>>>
>>>> It is an oddity
>>>> that other components that have choices (i.e. DropDownChoice, etc.)
>>>> provide a means to use an IChoiceRenderer, but some do not.
>>>
>>> the whole point of Radio/CheckGroup is to give the user more control
>>> then what IChoiceRenderer offers.
>>>
>>>> What if
>>>> someone is using a RadioGroup/CheckGroup that uses some form of a
>>>> RepeatingView to generate the Radio/Check options dynamically? In
>>>> the
>>
>>>> case where they need to make a selection using a separate choice
>>>> instance than what is in the list, how would they accomplish that?
>>>> If
>>
>>>> they set the choice on the RadioGroup/CheckGroup model it will
>>>> never
>
>>>> be selected because they are different instances, and because there
>>>> is
>>>
>>>> not IChoiceRenderer it is not possible to define an ID value to
>>>> determine the equality of the two instances.
>>>
>>> Not really sure what you mean here. The selection is based on the
>>> model object of Radio/Check, not the Radio/Check instance itself...
>>>
>>> -igor
>>>
>>>
>>>>
>>>> -----Original Message-----
>>>> From: Igor Vaynberg [mailto:[EMAIL PROTECTED]
>>>> Sent: Thursday, May 15, 2008 5:50 PM
>>>> To: users@wicket.apache.org
>>>> Subject: Re: IChoiceRenderer: RadioGroup CheckBoxMultipleChoice
>>>>
>>>> well, the whole point of radio/check group is to allow user
>>>> complete
>
>>>> control over markup. the whole point of choice renderer is to
>>>> automate
>>>
>>>> markup generation, so there is just a big mismatch. eg i always use
>>>> radio/check group when using a choice renderer would be
> inconvenient.
>>>>
>>>> you can always roll your own subclass, i just dont think something
>>>> like that would belong in core, its just one more parallel way of
>>>> doing something.
>>>>
>>>> -igor
>>>>
>>>> On Thu, May 15, 2008 at 2:44 PM, Hoover, William
>>>> <[EMAIL PROTECTED]>
>>>> wrote:
>>>>> yes... sorry CheckGroup is what I meant. It seems as though
>>>>> RadioGroup/CheckGroup should also have the capability of using an
>>>>> IChoiceRenderer as well, right? One reason I was thinking that is
>>>>> if
>>
>>>>> someone has a model object instance A that is a different instance
>>>>> than any of the choices in the list, they can override the
>>>>> IChoiceRenderer#getIdValue(...) and provide the identifier. Even
>>>>> though none of the choices are the same instance of A they can
>>>>> still
>>
>>>>> determine equality for selection purposes using the ID value.
>>>>>
>>>>> -----Original Message-----
>>>>> From: Igor Vaynberg [mailto:[EMAIL PROTECTED]
>>>>> Sent: Thursday, May 15, 2008 4:47 PM
>>>>> To: users@wicket.apache.org
>>>>> Subject: Re: IChoiceRenderer: RadioGroup CheckBoxMultipleChoice
>>>>>
>>>>> checkboxmultiplechoice uses ichoicerenderer afaik, did you mean
>>>>> checkgroup?
>>>>>
>>>>> radiogroup/checkgroup work differently, they leave all text
>>>>> generation
>>>>
>>>>> up to the user so no choice renderer is required.
>>>>>
>>>>> -igor
>>>>>
>>>>> On Thu, May 15, 2008 at 1:01 PM, Hoover, William
>>>>> <[EMAIL PROTECTED]>
>>>>> wrote:
>>>>>> For consistency sake, wouldn't it be wise to use IChoiceRenderer
>>>>>> for
>>>
>>>>>> RadioGroup and CheckBoxMultipleChoice? Seems like a natural
>>>>>> solution
>>>
>>>>>> to override IChoiceRenderer#getIdValue(...) to infer IDs for
>>>>>> selection
>>>>>
>>>>>> comparison the same way that it is being done in DropDownChoice.
>>>>>> Otherwise, how else can you use two different model object
>>>>>> instances
>>>
>>>>>> that share the same ID to be selectable?
>>>>>>
>>>>>>
>>>>>> -----------------------------------------------------------------
>>>>>> -
>>>>>> -
>>>>>> -
>>>>>> - To unsubscribe, e-mail: [EMAIL PROTECTED]
>>>>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>>>>
>>>>>>
>>>>>
>>>>> ------------------------------------------------------------------
>>>>> -
>>>>> -
>>>>> - To unsubscribe, e-mail: [EMAIL PROTECTED]
>>>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------
>>>>> -
>>>>> -
>>>>> - To unsubscribe, e-mail: [EMAIL PROTECTED]
>>>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>>>
>>>>>
>>>>
>>>> -------------------------------------------------------------------
>>>> -
>>>> - To unsubscribe, e-mail: [EMAIL PROTECTED]
>>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>>
>>>>
>>>>
>>>> -------------------------------------------------------------------
>>>> -
>>>> - To unsubscribe, e-mail: [EMAIL PROTECTED]
>>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>>
>>>>
>>>
>>> --------------------------------------------------------------------
>>> - To unsubscribe, e-mail: [EMAIL PROTECTED]
>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>
>>>
>>>
>>> --------------------------------------------------------------------
>>> - To unsubscribe, e-mail: [EMAIL PROTECTED]
>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
