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]
