i am +0 also if people don't want the List/Collection constructors. and maybe this is even better because you should do it through the model and not a list then that list and its values will be in the session, so if we only have model constructors people think more about the lazy loading of the list and detaching it?
I agree for the 2 differences they are not forks they are just targeting different things. For the most part you don't want to have so specify the <option> in the html that is not important for the most selects. But they can move to core. Just like RadioChoice/RadioGroup Maybe in a better package or naming so that people know that X generates everything and Y you specify the markup..? johan On 1/10/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
the difference between Select/SelectMultiple/SelectOption/SelectOptions and ListMultipleChoice is that the former allow you total control over the markup by separating the select tag and the options html so you can use <optgroup> etc, while listmultiplechoice generates the entire markup for you. ListMultipleChoice is great for quick drop down boxes, while select is great for when you need nonstandard markup. so they are really complementary. the reason there are so many constructors is that we provide too many convinience constructors. for example, instead of only having (..., IModel, IModel) we provide (..., IModel, List), (..., Collection, List), (..., Collection, IModel), etc we can remove these constructors, but all it will do is just make your code longer instead of new ListDropDownChoice(...., options) you will have to do ListDropDownChoice(...., new Model(options)) i am +0 on removing some constructors, i dont mind writing a bit of extra code personally -igor On 1/9/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > > There are a couple of components in extensions that are alternatives > (a better description for them than branches, as they typically > provide the same functionality, but have a different code base) for > the ones in core. It's one of the reasons for extensions' existence in > the first place. I don't think that is bad per se, but it is a good > idea to keep evaluating these alternatives and see whether they should > replace the originals. And in fact, we do that as you can see from the > move of some of the repeater packages to core (though they don't > replace ListViews, we'll shift the focus to repeaters). > > I don't know whether SelectOptions is a better component as I never > used it and don't know for what reason it is there in the first place. > Maybe Igor can clarify. Also I'm not sure whether IOptionRenderer and > IOptionRenderer really do the same thing; this is of course also bound > to the component that uses them. And regarding DropDownChoice and > ListMultipleChoice. Yes the components aren't the prettiest ones. But > I think the main reason they have so many constructors is because you > can create them in one statement, rather than having to create and > then call a bunch of setters. But yeah, maybe we could get rid of a > few constructors. Did you have concrete ideas on that? > > Eelco > > > On 1/9/07, Jean-Baptiste Quenot <[EMAIL PROTECTED]> wrote: > > Hi, > > > > I'm trying to understand every bit of the repeater package, and > > stumbled across a few things in wicket-extensions: > > > > * SelectOptions looks like a fork of ListMultipleChoice > > * IOptionRenderer looks like a fork of IChoiceRenderer > > > > Is it really needed? Personally I find IOptionRenderer better > > than IChoiceRenderer. If it shall makes its way into Wicket core, > > a decision should be made, but forking classes is not really good. > > It seems to me that a bunch of classes were rewritten to have a > > cleaner API, but no consensus was reached to unify. > > > > If I compare further, ListMultipleChoice is very hard to use: it > > has *ten* different constructors! Compared to two constructors in > > Select... DropDownChoice with *nine* constructors is not in a > > much better shape! > > > > Everytime I need to use DropDownChoice or ListMultipleChoice, > > I'm puzzled. We should do something about that... Or removing > > the forked classes. I don't see the point of keeping in > > wicket-extensions classes similar to others in core. > > > > To summarize there are a few things that could be done: > > > > * Reuse some ideas from extensions to core (like the IOptionRenderer) > > * Try to simplify core components (ListMultipleChoice and DropDownChoice > are awful) > > > > WDYT? > > -- > > Jean-Baptiste Quenot > > aka John Banana Qwerty > > http://caraldi.com/jbq/ > > >
