Glazed lists

[adepue]

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.

- Andy

[adepue]

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. :-)

- Andy

[Keith Donald]

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.

[adepue]

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

[steve_smith]

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?

[adepue]

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

[Keith Donald]

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...

[swankjesse]

Hi Steve, Adapue, Kieth --

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!

And finally, a very silly reason to use Glazed Lists: prettier sort indicator icons. I've wasted hours and hours drawing pixel-perfect icons for many look-and-feels: http://publicobject.com/glazedlists/sortedjtables/

So look at Glazed Lists and let me know if you're interested. I'm definitely glad to help! Please post your ideas to this forum, I've bookmarked it.

Cheers,
Jesse Wilson

[Keith Donald]

I'm sold. Thanks Jesse for that post, it was quite swank. :-)

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:

public interface Constraint {
    public boolean test(Object argument);
}

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.)

All of this 'glaze' talking is making me quite hungry. :-)

Thanks!

Keith, founder Spring Rich

[swankjesse]

Hey Keith --

Awesome news! As for your question, Glazed Lists regrettably does not have such an interface. I do think it is a great idea though.

Currently, we have something similar:

    public abstract class AbstractFilterList extends TransformedList {
        public abstract boolean filterMatches(Object o);
        public void handleFilterChanged();
        ...
    }

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:

    public class ConstraintFilterList extends AbstractFilterList {
        private List constraints = new ArrayList();
        public void addConstraint(Constraint c)  {
            constraints.add(c);
            handleFilterChanged();
        }
        public void removeConstraint(Constraint c) {
             constraints.remove(c);
             handleFilterChanged();
        }
        public boolean filterMatches(Object o) {
            for&#40;int c = 0; c < constraints.size&#40;&#41;; c++&#41; &#123;
                Constraint constraint = constraints.get&#40;c&#41;;
                if&#40;!constraint.test&#40;o&#41;&#41; return false;
            &#125;
            return true;
        &#125;
    &#125;

Well I've written enough code for a Friday night! I look forward to working with you and the Spring RCP team!

Jesse