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]
