we can have a Select component that acts like the CheckGroup component, and a SelectChoices component that works like the dropdownchoice with the exception of rendering <select> tags. We also have a SelectChoicesGroup which is a simple webmarkupcotainer with a builtin label attr modifier.
that way you have all the flexibility, the java code can look like this:
Select select=new Select("sel");
Choices nogroup=new Choices("nogroup", mylistofchoices, choicerenderer);
select.add(nogroup);
ChoiceGroup group1=new ChoiceGroup("group1", "this is group 1 choices");
select.add(group1);
group1.add(new Choices("group1choices", mylistofchoices2, choicerenderer));
and html will look like this
<select wicket:id="select">
<option wicket:id="nogroup"></option>
<optgroup wicket:id="group1">
<option wicket:id="group1choices"></option>
</optgroup>
</select>
what do you think?
-Igor
-Igor
On 11/4/05, Andrew Berman <[EMAIL PROTECTED]> wrote:
Yes my bad, I meant the "label" attribute, I got it confused with the label tag's "for" attribute.
I'm not sure what the best solution is either. Passing a string in definitely works, but it's not really consistent with the rest of the Wicket components (except Label which just takes the string and creates a new model with it). Nevertheless, I use i18n in my app and I use the getString(...) method all over the place, so passing in a String is, IMHO, not a bad thing.
Ok, what if we made OptGroup a component just like DropDownChoice, as you mentioned. Then couldn't we just do a test in the DropDownChoice/MultiChoice constructors to see if the list/model contains OptGroups? The only problem is what does the ChoiceRenderer passed into the DropDownChoice refer to at that point? How to display the optgroup or display the options? Should optgroup take in a ChoiceRenderer?
--AndrewOn 11/4/05, Igor Vaynberg < [EMAIL PROTECTED]> wrote:unless of course we just pass in a string instead of imodel and leave i18n to the user...
-Igor
On 11/4/05, Igor Vaynberg < [EMAIL PROTECTED]> wrote:you mean for the "label" attribute? Optgroup in this case wouldnt be a component so the IModel provided needs to be attached to some component so that it is detached properly, so the user needs to worry about attaching it somewhere, and the more optgroups you have the trickier that gets.
-Igor
On 11/4/05, Andrew Berman <[EMAIL PROTECTED] > wrote:Igor, why wouldn't the model be attached to the OptGroup object? Each OptGroup takes a model which is used for the "for" attribute.On 11/4/05, Johan Compagner <[EMAIL PROTECTED]> wrote:For the other choice objects (The singleselectchoice, dropdownchoice)
we could have a list of optgroups and the optgroup has a list of its choices
So you are just makeing one line with choices and optgroups (with again a list of choices)
johan
On 11/4/05, Igor Vaynberg <[EMAIL PROTECTED] > wrote:havent decided what the best way to do this is. one problem i see with passing a list of optgroups is that the optgroup will have to have an IModel for its label in case someone wants to i18n it, but then how do we handle attaching and detaching that model since its not attached to any component. maybe separate components like check and checkbox are the best way, and have an optgroup that works exactly like dropdown choice to simplify things.
still thinking,
thoughts?
-Igor
On 11/3/05, Igor Vaynberg < [EMAIL PROTECTED]> wrote:yeah sorry, think of it as pseudo html :)
-Igor
On 11/3/05, Andrew Berman <[EMAIL PROTECTED] > wrote:It would be similar to Check/CheckGroup because you could create a Select object, which is like the CheckGroup object, and an Option object, which is similar to the Check object. By doing that, then I can manually insert the <optgroup> tag either directly in the HTML or using a WebMarkupContainer in the JavaCode if the label needs to be dynamic. However, your thought about having an OptGroup object and extending the current DropDownChoice (and it makes sense to do the ListMultipleChoice too as you can use OptGroup with a select box that allows multiple choices) intrigues me. Maybe that is the smoothest way to go because it will reuse what's already available and would only add the one OptGroup component. I like it.
By the way, your html should look like below, your HTML above is not correct:
<select wicket:id="selectGroup">
<optgroup label="Label 1">
<option></option>
<option></option>
</optgroup>
<optgroup label="Label 2">
<option></option>
<option></option>
</optgroup>
</select>
--AndrewOn 11/3/05, Igor Vaynberg <[EMAIL PROTECTED] > wrote:I dont really understant what you mean.
If you want to do it like the Check/CheckGroup is done you would have a SelectGroup and Select components that you would put into your html and then you can manually insert <optgroup>
ie
<select wicket:id="selectGroup">
<optgroup>wicket doesnt care</optgroup>
<select wicked:id="choice1">
<select wicket:id="choice2">
</optgroup>
</select>
But then you are talking about making it a single component, so that is not like the Check/CheckGroup work.
If i was going to build it as a single component I would use the embedded objects like you mentioned, not a map. Ie
class OptGroup { List choices; IModel title; }
and my component would take a list of optgroups.
OR maybe something smoother would be to do extend the current DropDownChoice to do an instanceof check on the item its rendering and if its an OptGroup object write out the OptGroup.
Thoughts?
-Igor
On 11/3/05, Andrew Berman <[EMAIL PROTECTED] > wrote:I'm sure this is Igor's territory, but I was wondering if, like how Check/CheckGroup and Radio/RadioGroup was done, if we could also add something to permit optgroups. My thought was to have something like a Select object which takes a list of OptGroup components. The OptGroup component then takes a list of SelectOption components.
The other way I was thinking about it was to add a constructor to DropDownChoice and ListMultipleChoice which takes a Map. Then each Map key could be the optgroup value and the value could be a list of what should appear within that optgroup.
Thoughts?
--Andrew
