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

[Bruno Borges]

I'm afraid that it can't be possible to abstract more (using java.util.Collection) simply because choices _must_ be positioned with indexes. How to locate an object after the submit based on some selection?

If it were implemented with Collection as the return type, would be possible to use an instance of Set, and this way how to identify an object back on the server-side?

getChoices() must be kept as the way it is.

If I am wrong, please someone notifies me, and explain why... :D

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

--
Bruno Borges
[EMAIL PROTECTED]
Sun Certified Java Programmer for 1.4
Sun Certified Web Component Developer for 1.4