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]
