Java and Selections Part Three: Core Controls and Sorted Lists

Home » Java and Selections Part Three: Core Controls and Sorted Lists

Ok. So we’ve seen we can pass a Vector or an ArrayList into a selectItems control for a Combo Box or Radio Button. And we’ve seen we can pass it via SSJS or EL (but EL is slightly more efficient). That’s all well and good if your options are already unique and already sorted. But what if they’re not.

Well you could run an @Unique and a JavaScript sort once you’ve retrieved it. But part of the point of using Java is better performance, easier debugging and avoiding coding directly on your XPages. Remember that our getKeyEnts() method got values from a keyword. Consider if we’re using the same kind of code multiple places in our application and we refactory the getKeyEnts() method to call a static getKeyVals(String) method in a utilities Java class. We’d need to code our @Unique and JavaScript sort every single time, rather than putting it in that one static method.

(Just to deconstruct that for newer Java developers, this means a getKeyVals method that takes a String parameter and is stored in a utilities class. By making the method static, we can call it by just using myClass.getKeyVals(keyStr) instead of creating an instance of myClass first.Utilities classes tend to contain static methods.)

So we need to look for an equivalent to @Unique and sort in Java, don’t we. No, we don’t. Because I started the introduction by mentioning that cheat sheet of Java Collections. I’ve put the link here again in case you didn’t download it yet. Go and do it. Note the columns Ordering and Allow Duplicates. And notice the row for TreeSet, especially the notes:

A very nice alternative for ArrayList if
**Do not want repetitions
** Sorted order

A Set, like a List, contains only values, no keys. So yes, this gives us exactly what we want, out of the box.

Almost.

Because you can’t put a TreeSet directly into a selectItems control. So we need to convert the TreeSet to something that can be put it in the control. And this is also where I come back to the mental block I was having that there is no Java class called java.util.Array. Time for more code:

public String[] getKeyObj() {
Database currDb = ExtLibUtil.getCurrentDatabase();
View vwUser = currDb.getView("Keywords");
ViewEntry ent = vwUser.getEntryByKey("ACQUIRED SKILLS", true);
Vector<String> users = (Vector<String>) ent.getColumnValues().get(1);
TreeSet<String> test = new TreeSet(users);
String[] retVal = new String[test.size()];
retVal = test.toArray();
return retVal;
}

There is no Java class called java.util.Array because String[] is the notation for a String array. We create a new TreeSet passing the Vector into the constructor – the same syntax would be used for an ArrayList and we would use new ArrayList() to initialise it blank. The good news is that by passing the Vector into the TreeSet it automatically de-dupes and sorts. We then create a new String array sized to the number of entries in the TreeSet. Finally we pass into the array test.toArray(). Simple and extremely powerful.

This handles all the core controls. But what if we want to use a ValuePicker. That’s a bit more complicated, but I’ll leave that for next time.

2 thoughts on “Java and Selections Part Three: Core Controls and Sorted Lists”

    1. Yes, indeed. A useful contraction of syntax, particularly if it’s being used in lots of places.

Leave a Comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Scroll to Top