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]

Reply via email to