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]
