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: [email protected] > 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: [email protected] >> 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: [email protected] >>> 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: [email protected] >>>> 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: [email protected] >>>>> 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]
