But actually, LoadResultListStoreBinding is even more impressive, wouldn't you agree:
public class LoadResultListStoreBinding<C, M, D extends ListLoadResult<M>> implements LoadHandler<C, D>
This might need to be a separate thread, but:
I had to write my own implementation because we needed to be able to execute a callback after the LoadHandler.onLoad event was fired. I realize that this will cause the ListStore to fire a StoreDataChangeEvent but that event (in fact, no event fired from the ListStore does) does not provide access to the list of beans in the store and we needed a (read-only) reference to this list.
Incidentally, since the LoadResultListStoreBinding.onLoad method calls ListStore.replaceAll, would you not agree that an enhancement might include read-only access to the list from that event?
StoreDataChangedEvent deliberatly does not provide that list, as it is, by definition, the contents of the store itself. Other events (remove, add, update) do provide references to the modified items. ListStore.getAll() returns an unmodifiable list of the current items in the store.
The Loader<->Store binding classes are meant to be simple ways to perform common tasks, but for uncommon cases, additional work will be required. Building your own load handler could be done inline, using an anonymous subclass for especially custom code that is unlikely to ever be reused.
The generics of LoadResultListStoreBinding are verbose - one of the few classes that require three arguments to make sense, but I think that it does make sense and is required - if you have another way to look at this, I'd be happy to discuss it.
LoadResultListStoreBinding<C, M, D extends ListLoadResult<M>> implements LoadHandler<C, D>
C is the config type - this alone could be cleaned out, as it is not used internally, but it would need to be specified as Object to be as permissive as possible. With that change, anything that would consume this instance (passed to loader.addListHandler) would need to be ? super C, which then gets hairy when the config is passed into the event and actually consumed by other event handlers.
M is obviously required, to make it clear what kind of data the store and loader hold in common.
D then represents the load result instance - again, we could make this concrete as ListLoadResult<M>, but then we would need to use wildcards when adding this handler to the loader - same problem as C.
My only concern was centered around custom UI components where the list store is not exposed because, technically, it didn't need to be. How then, does one get access to the data store? Once of the really nice things about event handling in general is it allows code to not be tightly coupled, i.e., the fired events provide all the data needed in the event handling method. I just think this makes for cleaner code.
I wasn't suggesting that the LoadResultListStoreBinding class was bad or poorly designed. I was merely commenting on the generics - they, of course, make sense. It does make for verbose code and I've given up trying to stay in the 80-character line boundary when dealing with certain classes due to the generics involved.
Asthetics, in my opinion, are not an area where Java wins any points. Java 7, with its diamond notation, might help shorten some of those terrible lines though...
All Store events expose the store instance itself, as the source of the event. An instance of StoreDataChangedEvent can have getStore() called on it to get the exact store instance which emitted the event - and if you have access to the event, it is assumed that you either know what kind of store it was, or don't need the specific methods available to that specific type. The getAll() method is defined on Store, so can be used without any cast at all.