• Type: Enhancement
• Component: javafx
• Sub-Component: base
• Affected Version: fx2.0

• Priority: P3
• Status: Closed
• Resolution: Fixed

• Submitted: 2011-09-21
• Updated: 2015-06-12
• Resolved: 2013-05-07

JDK 8
8Fixed

Verified for 8.0 b122 07-01-2014 I originally had transformation to base source index, but then I realized it might often mislead the caller and would be quite error-prone. Consider a class that accepts an ObservableList, does some wrapping around it and then transforms the indexes to the original ObservableList using the method on TransformationList. This fails if the original ObservableList is actually a TransformationList and the result is wrong in combination with the ObservableList that was passed to the class. I think it's better to always ask for the specific list to avoid such errors. Also, if you need an index, you most likely need an index of a specific list (whether it's the base list or not), so you can use it in that list. 06-05-2013 BTW, completely agree on "filtered" vs. "filter". "filtered" is the right thing as you mentioned. 06-05-2013 Only other thought is about the TransformationList class, and transforming the index. I saw a method which transforms to the immediate wrapped list, and one for transforming to a specific list in the chain, but not one for transforming to the "base source index" (or whatever the right name would be) -- the source index after transforming through the entire chain. I figured this would be the most common one, since I might: ObservableList original = ...; TransformationList transformed = original.filtered(...).sorted(...).filtered(...); listView.setItems(transformed); listView.getSelectionModel().selectedItemProperty().addListener((observable) -> { Object item = original.get(transformed.getBaseSourceIndex(listView.getSelectionModel().getSelectedIndex())); }); 06-05-2013 Comparator and Predicate properties need documentation, but otherwise looks good. 06-05-2013 Richard, do you have any other concerns or can I get "api-approved" label for this issue? Thanks. 06-05-2013 - Made the properties final There was a typo, it should have been filtered. I think filtered and sorted imply continuity of the state, while filter/sort look more like a one-time action. 02-05-2013 On the ObservableList method names, we should either have "filtered" and "sorted" or "filter" and "sort". I'm not sure which makes more sense. 30-04-2013 I think since then we've decided to go Java 8 across the board (even iOS / Android) so using defender methods shouldn't be a problem. Please do make the methods final even if the class is final -- partly for my own OCD :-). If in the future the class is made non-final for some reason we won't accidentally leak non-final setters / getters as well. Thanks! 30-04-2013 Attached new webrev. The changes outside of javafx-beans were needed in order to build with javac.source=1.8, javac.target=1.8. I've updated the javadoc and renamed onSourceChanged to sourceChanged. The setters and getters in SortedList/FilteredList don't need to be final, as the classes themselves are final. I've included also the defender methods to ObservableList, although in your previous comment (from Feb 14) you wanted to add defender methods in some later release, probably because of embedded (?). 30-04-2013 Also were we going to have default methods on ObservableList to filter / sort as in: someList.filter(predicate).sort(comparator).filter(otherPredicate); 29-04-2013 Also please make sure the getters / setters are final, I see in SortedList for example comparatorProperty(), setComparator(Comparator value), getComparator() are all non-final. 29-04-2013 107 * Called when a change from the source is triggered. 108 * @param c the change 109 */ 110 protected abstract void onSourceChanged(Change<? extends F> c); Do we use this naming pattern elsewhere for a method that is intended to be overridden? javafx.concurrent API used "succeeded", "started", "running" etc names for such methods. So maybe "sourceChanged" would be the name of this method instead? The "on" prefix I believe has been used only for event properties. 29-04-2013 isInTransformationChain method is missing javadocs, also getSourceIndexFor method (both on TransformationList) 29-04-2013 Waiting for JDK8 Lambdas to finish this feature. 27-03-2013 @Martin Sladecek: Not sure if it's what Richard Bair had in mind but in the application that we are currently developing it would be useful to have a list filtered by index, e.g. a sublist backed by another list. Generally I would like to be able to have an observable Sublist that has: * the first X elements of the backing list * the last Y elements of the backing list Of course X/Y should itself be observable values. 26-02-2013 That's a different kind of filtering, so I think we should create a different TransformationList implementation for this (some kind of live sublists). Once TransformationList is in the repository, it should be pretty easy to implement. I guess there will be lots of different requests on TransformationLists based on personal needs, so it may be something for the JFXtras project. 26-02-2013 Webrev attached. Note: I don't think we need property for the wrapped list, as it cannot change, so there's only a getter for it in TransformationList. Not sure what do you mean by from/to indexes. 25-02-2013 Long discussion on this on the phone and especially on the mailing list. The decision on this is to: - Make SortedList & FilteredList & TransformationList public classes - SortedList & FilteredList will have properties (for comparator / predicate / etc) and default constructors - SortedList & FilteredList (probably) also need to have properties for the list they wrap, and to/from index methods etc - SortedList & FilteredList will be unmodifiable but mutable -- meaning as the filter changes or the source list changes the SortedList / FilteredList changes, but you cannot directly modify the sorted / filtered list - TableView / TreeView / ListView / TreeTableView will have API added to them to allow sorting / etc such that, if a developer uses a SortedList with a TableView (for instance) then they will have to also handle the sorting such that any sort comparators on the TableView are bound to the comparator on the SortedList - We will look at adding the defender methods to ObservableList a little later (although we definitely want to add them at some point) Martin, can you work up and post the diff / code? I will do a quick check and mark approved. 14-02-2013 We actually deferred this to Lombard, for (at least) these 2 reasons: - It looks like there's going to be some functional overlap with Java collections in JDK8 - There's going to be Predicate interface in JDK8, which we can use for FilteredList, but we cannot use it now. 07-02-2012 I forget if this is actually still targeted at Lombard, or if an attempt is likely to be made for JavaFX 2.2? I'd love to see it sooner if at all possible. 06-02-2012 SQE relies on unit tests for collections testing. If dev can provide sufficient coverage - there is no impact on SQE 02-12-2011