GlazedLists is not "GUI-Lists"!

This is a post in Praise of GlazedLists - at least the concepts it embodies!

It took some time before I "got" GlazedLists.

I had read several articles about GL, and went to a JavaOne 2008 talk about it, but I still didn't actually grasp it: I feel that GL's presentations always centers around GUI aspects, in particular list-views and other boring stuff. This was not a good way to sell it to me: I weren't a particularly huge fan of "binding frameworks" and the like. However, I did see something through that GUI-haze, and when I finally did get down into GL, I pretty much immediately rewrote my current project to use it from the core outward! GL's concepts have nothing to do with GUI in themselves! It is just that the concepts are really very handy when it comes to several GUI aspects. I now believe GL have utility for any system which have a state consisting of a dynamic set of entities - not only for the "last mile", the actual display to the user, but as a core tool to build ones entity handling on.

The main concept of GL is actually not very "big" as such. I'll try to formulate a phrase that would have had me get the concept:

 " GL is at its core a modifiable List of objects, where sorting (reordering), selections (filtering) and transformations can be applied in a chain, resulting in new list views of the parent list, and the entire chain of lists is kept updated no matter where modification methods are invoked on that chain, by propagating the incremental change events internal to the chain, not needing an external event structure. "

Was that understandable?

Think about a system that has a List-of-Customers in the base. You then sort that list based on the customers' last name, getting a new list. Then you filter the list, for example selecting all the customers of age 40 or more. Yes? This resulting list is used often, so you keep a reference to it, "caching" it so to speak.

But then you get a new customer.

If you don't know GlazedLists, you now immediately think about some "NewCustomerEvent" that the container of the base list fires, on which the cache-holder listens, and upon receiving such events, it does the filtering, then sticks it into the list at the correct sorted position. Then you start thinking about customers that want to leave, and realize that you need a "CustomerDeletedEvent". And then, what if the customer was entered with the wrong name or age?

If you do know GlazedLists, you just smile! :-)

The base EventList gets the customer inserted, and sends an internal event up to the listeners, and first hits the SortedList. Here it is inserted at the correct position, but the sortedlist propagates the change further, up to the FilterList, which applies the filter, and now both the intermediate list and the age-40-filtered list is updated, "just like that". You may even change the sort-order, or the filter, and things are always correct.

You may also hook onto the event fire system at any point.

Now, this happens to be exceptionally useful for GUIs where it can keep different views "magically updated" when the internal state of the system changes, and GL also have lots of such utility classes that handle common "binding cases", but the main concept is useful for pretty much any stateful system that have dynamic set of entities as its state.

So, yes: Everyone should check out GlazedLists, not only the die-hard Swing/SWT GUI developers! It is definitely a tool that should be in any serious coder's tool chest blah blah..!