Re: IChoiceRenderer: RadioGroup CheckBoxMultipleChoice
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: users@wicket.apache.org
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: users@wicket.apache.org
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: users@wicket.apache.org
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 ListMyObjectOption myObjectOptionList = new
ArrayListMyObjectOption(); 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
Re: IChoiceRenderer: RadioGroup CheckBoxMultipleChoice
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: users@wicket.apache.org
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: users@wicket.apache.org
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: users@wicket.apache.org
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 ListMyObjectOption myObjectOptionList = new
ArrayListMyObjectOption(); 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
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 ListMyObjectOption myObjectOptionList = new
ArrayListMyObjectOption();
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: users@wicket.apache.org
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: 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
RE: IChoiceRenderer: RadioGroup CheckBoxMultipleChoice
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: users@wicket.apache.org
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 ListMyObjectOption myObjectOptionList = new
ArrayListMyObjectOption(); 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: users@wicket.apache.org
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: 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
RE: IChoiceRenderer: RadioGroup CheckBoxMultipleChoice
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: users@wicket.apache.org
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: users@wicket.apache.org
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 ListMyObjectOption myObjectOptionList = new
ArrayListMyObjectOption(); 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: users@wicket.apache.org
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
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: users@wicket.apache.org
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: users@wicket.apache.org
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 ListMyObjectOption myObjectOptionList = new
ArrayListMyObjectOption(); 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: users@wicket.apache.org
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
RE: IChoiceRenderer: RadioGroup CheckBoxMultipleChoice
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: users@wicket.apache.org
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: users@wicket.apache.org
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: users@wicket.apache.org
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 ListMyObjectOption myObjectOptionList = new
ArrayListMyObjectOption(); 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
Re: IChoiceRenderer: RadioGroup CheckBoxMultipleChoice
afaik value is not used in checkbox or radio, not even sure that its
valid to have it.
iidentfierrenderer is a bad name since the id isnt actually rendered...
-igor
On Fri, May 16, 2008 at 9:07 AM, 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: users@wicket.apache.org
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: users@wicket.apache.org
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: users@wicket.apache.org
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 ListMyObjectOption myObjectOptionList = new
ArrayListMyObjectOption(); 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
RE: IChoiceRenderer: RadioGroup CheckBoxMultipleChoice
It is valid to have a value on a checbox/radio
http://www.w3.org/TR/html401/interact/forms.html#h-17.4
I agree that the name of the interface needs to be addressed. The
concept is what I was attempting to convey.
-Original Message-
From: Igor Vaynberg [mailto:[EMAIL PROTECTED]
Sent: Friday, May 16, 2008 12:16 PM
To: users@wicket.apache.org
Subject: Re: IChoiceRenderer: RadioGroup CheckBoxMultipleChoice
afaik value is not used in checkbox or radio, not even sure that its
valid to have it.
iidentfierrenderer is a bad name since the id isnt actually rendered...
-igor
On Fri, May 16, 2008 at 9:07 AM, 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: users@wicket.apache.org
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: users@wicket.apache.org
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: users@wicket.apache.org
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 ListMyObjectOption myObjectOptionList = new
ArrayListMyObjectOption(); 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
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]
RE: IChoiceRenderer: RadioGroup CheckBoxMultipleChoice
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]
RE: IChoiceRenderer: RadioGroup CheckBoxMultipleChoice
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]
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: 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]
