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
- Map synchronization (syncEventListToMultiMap, etc).,
- Concurrency - live UI updating of work going on in a background thread (loading, searching, whatever).
Which features are you considering?
- (2) tree stuff
- (2) NetworkList, some kind of client-server list synchronization.
- RangeList (A paginated view of an EventList)
- Auto completion support
- map synchronization
- JFreeChart support
- Hibernate support
What does your application do?
- frontend for bank dealing room
- client for desktop and enterprise search
- financial accounting system for transportation industry, w/ GIS
- automating finance processes
- stock trading
- financial app for payroll, balance and tax
How can we improve our documentation?
- 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.
What do you like about Glazed Lists?
- 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.
What are we doing wrong?
- 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.
Improving our process
- 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
- Search (filter) based on lucene.
- (2) Performance, especially for sorting and filtering large ( > 100,000 elements) EventLists.
ListEvent should be smarter
- (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
I use a database
- Out of the box Hibernate integration.
- bind an EventList to a JDBC RowSet, updating the database on edits
Locking should be easier...
- 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:
all the time, I should be able to shorten it to just:
- 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.
Give me BufferingList/TransactionalList
- 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