I agree with your view on keeping Wicket from being bloated. What if the IChoiceRenderer was optional? If you provide it you have automation. If you do not it works as it does now.
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). 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. 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. -----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]
