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]