Users Survey

Development‎ > ‎

Contents

What features of Glazed Lists are you using?

(8) Sorting (Live sorting)
(8) Filtering (Lots of filtering.), Live searching via filterators, matchers, matcher editors, etc.,
(5) autocomplete support
(3) Swing integration, Lots of table integration (AdvancedTableFormat, EventTableModel, EventSelectionModel),
(3) binding the lists to Swing
(2) SWT.
(3) GroupingList
(2) UniqueList
(2) FunctionList
TransformedList
FreezableList
ThreadSafeList
DebugList
Generics
ObservableElementList,
CollectionList
CompositeList
SeparatorList
Map synchronization (syncEventListToMultiMap, etc).,
Concurrency - live UI updating of work going on in a background thread (loading, searching, whatever).

I'd love to see more screencasts. I learn more in five minutes watching one of those then I do in five hours of reading API documentation. I like to run them forwards and backwards.
Generics helps a lot to make the code self-explained.
With the work that has been put into Glazed Lists to be as intuitive as possible, it has been relatively easy to learn.
The screencasts definitely help walk through some of the more common tasks getting started with Glazed Lists.
the responses on this list are excellent.
Provide some kind of system documentation for new contributors.
The only area of difficulty might be the "gotchas" such as event publisher dependencies (is this even a problem anymore?), concurrency, and EDT issues. Those last two are no fault of GlazedLists (they are difficult problems with or without GlazedLists), though GlazedLists certainly tries to make them easier to deal with.

In general, Glazed Lists is easy to use for the standard tasks (sorting, filtering in tables ...). You get productive very quickly.
Compare GlazedLists with most other projects out there, and you see that somehow it has managed to consistently come up with an easy approach to most things.

There's always a few bugs here and there, but every project has that. More unit testing would help.
In the past I've also struggled with table selection problems - I'm not sure if these still exist (I came up with a workaround long ago, so I won't notice a fix internal to GlazedLists)?
Release more often with smaller increments.
forgetting to dispose TransformedLists can cause memory leaks.

SWT and JFace is currenty being addressed. This is very important to me, and I'm trying to help here and there.
I think SWT/JFace and Swing are different enough that they should be separate extensions.

GlazedList codebase could be refactored to more strictly enforce separation among modules and make it more evident. It would have a core component that everyone would use for list transformations, event processing, etc. that is totally independent of the type of widget, chart, etc. being used. The developer would only use the separate extensions for Swing, SWT, JFreeChart, etc. that they need. Communication between the core and an extension would *only* occur through defined, public APIs--not through any internal stuff.

In-cell editing needs a well-defined hook for validation
(2) A GroupingList where each sublist is an EventList.
GroupingList: change grouping criteria dynamically
(3) TreeList: support for Trees and TreeTables would be awesome.
Integration with visualization libraries such as JGraph and Prefuse. Simple graphing of TreeList, GroupingList, etc, would be a good start.
Search (filter) based on lucene.
(2) Performance, especially for sorting and filtering large ( > 100,000 elements) EventLists.
stability...

(2) ListEvent should provide the deleted element, Some of my custom EventLists could benefit from this.
provide 'element moved' event
Paging support in Jtables for EventLists

Make locks reentrant? If my thread already holds a write lock on an EventList, I could obtain another read lock or write lock on the same list in the same thread. The locks would use a counter to know how many times my thread has locked a list so it knows if I have the lock and unlock calls balanced.
Rather than having to write:

     mylist.getReadWriteLock().writeLock().unlock()

all the time, I should be able to shorten it to just:

     mylist.writeUnlock().

Correct locking can be tricky (CollectionList/CompositeList!)
Locking can be rather complex if you write your own transformations. We often have the case that the EventLists are buried within some complex model hierarchy. This model hierarchy gets replaced by a new instance. Hence, we cannot always easily enforce that all lists used in a composite share the same lock.
From a developer view, it's not always clear to me, when a list implementation should aquire the required locks itself or should rely on the calling client code to hold the locks.

I would like to see the BufferedView idea fleshed out so that you can try out changes to an EventList and then call commit to propagate those changes to the backing EventList as a single event. You should be able to have multiple views open on the same backing EventList. I would like to be able to begin, commit or rollback the changes kind of like you can with a database transaction. See: https://glazedlists.dev.java.net/servlets/ReadMsg?list=users&msgNo=1462
I would like to see batching added to the event mechanism to increase performance. For example if I call addAll() to add 10,000 objects to a SortedList, it would do the insertion as one batch and then sort the indexes rather than do 10,000 separate ordered insertions.

Comments