If the list is sorted then indexOf could go faster.
I use a list impl that i want or like for that specific case.
I prefer to go the other way. Less just plain loops to find something.
More let the user decide how to find it.
Don't know a good and simple way to do that right now.
johan
On 5/11/06, Alexei Sokolov <
[EMAIL PROTECTED]> wrote:
Johan,
In my eyes today:
1. We don't have default implementation of SortedList. java.util.List.indexOf is not that efficient
2. We cannot use java.util.Set because we are affraid of loosing performance advantages of #1, which is nil until we have SortedList.
AlexOn 5/10/06, Johan Compagner < [EMAIL PROTECTED]> wrote:The choicerender is just a default implementation of IChoiceRenderer
I have made lots of quick others so we can assume anything of an idExpression..
That there is no SortedList in the 1.5 spec is just stupid i made a RFE for that long long long time ago.
I have my own class that is used a lot in my code. Because for pretty much everything where i sort, a list is most of the time what i want
because i also want to be able to get it by index (ListModels of Swing comes to mind)
And a sorted list is much lighter then a TreeMap (not even speaking of a TreeSet which is another wrapper around a SortedMap)
johanOn 5/10/06, Alexei Sokolov <[EMAIL PROTECTED]> wrote:First, why: so it will be possible to use java.util.Set, for example.
Second, how:
You generate a list of items on the server side. You will always be able to identify your object if the way you are searching for it and the way you generate your original list are consistent among each other, i.e. if you use an iterator and a counter in both instances, you should be fine.
About performance, first you should realize that if ChoiceRenderer is used and idExpression is specified, than the result of index lookup is not used anyway ( i.e. lookup is performed, and then its results are ignored). So if you want to improve performance, code could be refactored to check if idExpression is specified and then do not perform indexOf in that case (I think it should be done even if java.util.List stays). Also, please point me to SortedList implementation within j2se 1.5. SortedSet is there, btw.
AlexOn 5/10/06, Bruno Borges <[EMAIL PROTECTED]> wrote: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... :DOn 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.
AlexOn 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.
-IgorOn 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
