it is used for radios, for checkbox its "on" if checkedand no
requestparam at all if its not.

at least thats what i remember from the "dark ages"

-igor

On Sun, May 18, 2008 at 12:59 AM, Johan Compagner <[EMAIL PROTECTED]> wrote:
> Isnt the value used by us already??
> To know what checkbox/radio is selected?
>
> On 5/16/08, Hoover, William <[EMAIL PROTECTED]> wrote:
>> It could be left as is and use the display value as expected (i.e.
>> <input type="checkbox" id="ID_VALUE" value="DISPLAY_VALUE"  />).
>>
>> Another option would be to have an identifier renderer:
>>
>> public interface IChoiceRenderer extends IIdentifierRenderer
>> {
>>       Object getDisplayValue(Object object);
>> }
>>
>> public interface IIdentifierRenderer extends IClusterable
>> {
>>       String getIdValue(Object object, int index);
>> }
>>
>> -----Original Message-----
>> From: Igor Vaynberg [mailto:[EMAIL PROTECTED]
>> Sent: Friday, May 16, 2008 11:47 AM
>> To: [email protected]
>> Subject: Re: IChoiceRenderer: RadioGroup CheckBoxMultipleChoice
>>
>> 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]
>>
>>
>>
>> ---------------------------------------------------------------------
>> 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