Re: [Wicket-develop] Change AbstractChoice.getChoices() to throw a NPE if the choices are null?

[Johan Compagner]

The problem is that it is really a list, just that ListModel of swing really has getElementAt(index)
because in the end it is a list.

But i guess the the convertValue can be replaces by a iterator and an index counter.
But i am not happy with that anyway. I would much prefer a bit better lookup then just iterating until found.
But then we have to say to the choice renderer give me the element for this id. And then everything becomes much harder
and people now have some difficulties to understand it..

this " int index = getChoices(). indexOf(object);" can ofcourse also be done by just iterating.
But if you back it up by a sorted list or something like that.. then performance is much worse...

We could get rid of the index. But then simple list where you just do it by index are again much harder.
Because internally you have to generate somethign for the given object..

johan

On 5/10/06, Alexei Sokolov < [EMAIL PROTECTED]> wrote:

Code like this? from AbstractChoice: final Object choice = choices.get(index);
It can be refactored to use iterator, because it is used withing for loop.
The only problem I could find is this, but it also can be refactored:

    public final String getModelValue()
    {
        final Object object = getModelObject();
        if (object != null)
        {
            int index = getChoices(). indexOf(object);
            return getChoiceRenderer().getIdValue(object, index);
        }
        return NO_SELECTION_VALUE;
    }

You guys should know the code better, so I could miss something.

Alex

On 5/10/06, Igor Vaynberg < [EMAIL PROTECTED]> wrote:

Afraid this wont be as easy because the choice objects utilize the index property of the list. Maybe in 2.0 we can refactor to work with a collection if possible.

-Igor

On 5/10/06, Alexei Sokolov <[EMAIL PROTECTED]> wrote:

One more proposed change. Replace java.util.List with more generic java.util.Collection?

Alex