This forum is now a read-only archive. All commenting, posting, registration services have been turned off. Those needing community support and/or wanting to ask questions should refer to the Tag/Forum map, and to http://spring.io/questions for a curated list of stackoverflow tags that Pivotal engineers, and the community, monitor.

Glazed lists

Oct 20th, 2004, 01:09 PM

I love the automatic combo box and list binding features of SwingFormModel. I'm wondering if anyone has integrated this with Glazed Lists? If a property contains a glazed list, I'd like the UI to update whenever the list is updated. Note, the bean might declare the property as a List type, but might actually return an EventList instance.

I guess I shouldn't presume on the popularity of glazed lists. :-) For those who are wondering, here is the project's (new) home: http://publicobject.com/glazedlists/
BTW, I've noticed their new home server randomly decides to not return a response - so if the link above doesn't work, try again until it does. :-)

Comment

That's a good point. EventList is an interface right? We could add in special support for lists that can be asynchronously updated.

Glad you like the binding stuff. We're on to something there: JGoodies binding has a similiar design/concept, though we seem to have richer support for collections/nested/indexed/mapped properties (and property access strategies.)

This is a real critical area to develop: we want to get better with metadata-driven control selection and configuration, and better with automatic type conversion and validation.

Comment

Yes, EventList is an interface that extends List and provides (contracted) functionality for firing update events whenever the list is mutated. The Glazed List library also provides a list model, combo box model, and table model implementations that can wrap an EventList and automatically handle the EventList's update events. Moreover, the library provides transform lists and filter lists that can wrap other EventLists. For example, I can create a TransformList that wraps an EventList containing Entity instances and transforms the elements (dynamically) into a String list of Entity names via Entity.getName(). I can then wrap the TransformList in a search FilterList (that filters the names based on a search field) and then wrap the search FilterList with a sort list. All these implement EventList - and because of this, if I, for example, add an element to the root EventList, it will percolate through the entire "decoration stack" (for lack of a better term) -> from the root EventList to the TransformList -> to the FilterList (and if it survives filtering) -> to the sorted list. Anyway, you get the idea.

- Andy

Comment

For those who are wondering, here is the project's (new) home: http://publicobject.com/glazedlists/
BTW, I've noticed their new home server randomly decides to not return a response - so if the link above doesn't work, try again until it does.

I try link many time but is down. Please tell me...what is good about glaze list?

Comment

At its core, a glazed list is just the same as a Java List (from the Collections API), except that it fires events whenever it is mutated (that is, whenever items are added, removed, or changed). Because a glazed list implements the java.util.List interface, you can use it where you would use a List (or Collection). The cool part is that the glazed list API provides filters, transformers, and Swing adapters. For example, say you have a list of Person objects, and your Person object contains a "getAddress" method that returns the person's address. So, each "Person" has an Address. Now say you want to display all the addresses in a sortable table while providing a search text area. Glazed lists makes this easy. First, you can wrap your Person list in a Transformer that returns "person.getAddress" for each element. You have just created a list of Addresses without having to manage another list. This means you have two lists: a list of Person instances and a list of Address instances. However, the Address list isn't a separate list, it just transforms the elements of the Person list into Address elements. If code somewhere adds another Person to the Person list, that person's address will automatically show up in your address list, and because your address list fires events when it is mutated, then your address table UI will automatically update as well. Anyway, now that you've transformed your person list into an address list, you could then wrap it in a FilterList that will filter the addresses based on a search string entered in a text field. Finally, you can wrap that filtered list in a sort list that will sort the list according to the currently selected sort column on the table. With this final list, you can wrap it in a TableModel adapter that automatically exposes properties on the POJOs contained in the list (in our case, instances of Address) as columns in the table. So, for example, the "line1" property (accessed via "getLine1()") could be one column, the "state" property another, "zip" another, and so on. The TableModel adapter will automatically update the UI whenever the contained glazed list is updated, making asynchronous model updates easy.
Of course, there is nothing super magical about any of this - it was all possible before. Glazed lists just gives you a convenient "don't reinvent the wheel everytime" library.

- Andy

Comment

I'm wondering if we should officially integrate GlazedLists; we do have some overlapping capabilities already For example, we support mutable lists with event notifications via the ObservableList interface - which just combines List and ListModel. We support filters via the FilteredListModel interface, which builds on the Constraint interface. We don't really have the concept of transformed list. Hmm...

I am the lead developer for Glazed Lists, I found this forum via a referrer link to the Glazed Lists website. First off, my apologies for the site being down sparatically, I am looking into that as we speak. Try reloading a few times and if it fails I'll field complaints via email.

I am pleased to hear you are interested in Glazed Lists.

I acknowledge that the Spring RCP already overlaps in some areas, so I will cut right to the chase and attempt to convince you why Glazed Lists is worthwhile!

Glazed Lists is heavily optimized. Suppose you have a list decorator (such as your FilteredListModel), you must call an expensive method such as reallocateIndexes() every time a change happens. Glazed Lists has a custom, high-performance mapping objects that do this very very fast. There are specialty collections for sorting, filtering and removing duplicates.

Glazed Lists is one familiar API. I evaluated Swing's ListModel when designing Glazed Lists and decided it is insufficient to support high performance decorators. If you use ListModel, your performance will suffer. Developers don't like the ListModel interface, they like List interface. Besides, having both an AbstractTableModelFilter and and AbstractFilteredListModel is unnecessary duplication. Move the filtering upstream into the List interface!

Glazed Lists introduces list transformations. These are a simple and powerful programming technique. Let the model do the work for you!

Spring Rich is certainly about integrating good solutions, particularly those that specialize (and are well focused.) We aim to integrate them as part of a platform to support rich-client development end-to-end, and one that builds on the core Spring Framework for consistent configuration and application layering. Your glazed list project seems like the perfect project to partner with.

I have one basic question.

First, a little background: We have a Constraint interface for attaching filters to lists, for example, to present a view of the elements that meet the constraint criteria only. We have a rich factory for building all kinds of different constraints, including complex expressions (this same facility powers our declarative rich-client validation system.)

How do you configure filters with GlazedList? Is at is simple as implementing a "Constraint" type interface. Ours looks like:

Ideally we'd like to be able to take spring rich constraints and use them as filters with the GlazedLists. Would that be easy enough to do?

We also have a rich data binding framework that connects backing domain objects to GUI controls: glazed lists could help here in supporting async. updates of collections (which will automatically reflect in bound controls through our data binding library.)

The largest difference between this and a traditional constraint is that the filter can change over time. Consider the text filter in iTunes. As the user enters text, the filter changes what matches to only what includes the typed String. Therefore this 'constraint' must occasionally force the entire list to be re-filtered.

Of course, supporting constraints would only require the following code:

Comment

Comment

We also have a rich data binding framework that connects backing domain objects to GUI controls: glazed lists could help here in supporting async. updates of collections (which will automatically reflect in bound controls through our data binding library.)

is it pssible to do that ? I think Keith had suggested that while ago but I need to do it now, and I was wondering if someone can give me some pointers on how ?