Regarding both Neil's and Stephen's recent submissions on the topic of event support for collections,
I think I would prefer multiple listener interfaces and a simple event to a single listener interface and either a hierarchy of event classes or a typed-using-masks event. Information about the type of change is provided to the listener through the method that is called. I would also prefer different interfaces for simple and veto-able event notification, e.g. CollectionListener and VetoableCollectionListener. This leads to more interfaces than the current designs on the table CollectionListener VetoableCollectionListener ListListener VetoableListListener ... but feels better to me from a client point of view. michael On Thu, 24 Jul 2003, Stephen Colebourne wrote: > See http://www.scolebourne.eurobell.co.uk/Observed2.zip > This contains a simple observing collections decorator. > > My goals for [collections] is to add something small and simple that doesn't > prevent a user adding something more complex. > > There are relatively few classes involved here, and no tests. > > - ObservedCollection is the decorator. It calls ObservedHandler before and > after each method call. > > - ObservedHandler has two methods for each Collection method, one to be > called before and one after. (It will also have methods for List/Bag/Set/... > The standard implementation in the handler forwards all the methods to a > single point where the event is sent. Event filtering (from notifying colls) > is used on a per method basis. > > - ObservedEvent is the standard event class that stores values for all the > data that is available 'for free' from the method call. > > Positives: > Simple > Extendable by subclassing Handler/Event > Can swallow method calls without an exception if desired > Can cope with invalid boolean 'collection changed' flags if desired > > Negatives: > One Handler created per decorator > Event instance not shared between pre and post event > Listener process may not be quite right yet > > I can't access your server at present, so I can't compare. > Stephen > > From: "Neil O'Toole" <[EMAIL PROTECTED]> > > --- Stephen Colebourne <[EMAIL PROTECTED]> wrote: > > > I haven't forgotten this, and will release some code I've been > > > working on > > > for comparison soon. > > > Stephen > > > > Great, do you have a rough idea when you'll have that code out? > > > > N. > > > > > > > ----- Original Message ----- > > > From: "Neil O'Toole" <[EMAIL PROTECTED]> > > > To: "Jakarta Commons Developers List" > > > <[EMAIL PROTECTED]>; > > > <[EMAIL PROTECTED]> > > > Sent: Monday, July 21, 2003 9:01 PM > > > Subject: Re: [collections][submission] NotifyingCollections > > > > > > > > > > More updates: the source, jar, and javadoc have all been updated. > > > > > > > > http://nettool.sourceforge.net/nc > > > > > > > > Neil > > > > > > > > > > > > --- Neil O'Toole <[EMAIL PROTECTED]> wrote: > > > > > This is a much updated submission of the event-based notifying > > > > > decorator mechanism for collections, as discussed on the list > > > last > > > > > month. > > > > > > > > > > The package is too big to be posted to this list. The source, > > > > > javadoc, > > > > > and pre-built jar can be downloaded from: > > > > > > > > > > http://nettool.sourceforge.net/nc > > > > > > > > > > The javadoc can be viewed online: > > > > > > > > > > http://nettool.sourceforge.net/nc/api > > > > > > > > > > The best place to start is the package description for > > > > > o.a.c.collections.notifying. Either navigate from above, or > > > directly > > > > > via: > > > > > > > > > > > > > > > > > > > > http://nettool.sourceforge.net/nc/api/org/apache/commons/collections/notifyi > > > ng/package-summary.html#package_description > > > > > > > > > > > > > > > This release provides notifying decorators for Collection, Set, > > > > > SortedSet, List, Bag and SortedBag. Map and SortedMap > > > implementations > > > > > are present, but are not completed. > > > > > > > > > > NotifyingCollections uses pluggable event factories to generate > > > its > > > > > events. There are three such "event packages" included: 'simple', > > > > > 'rich', and 'monolithic'. The 'simple' package is a bare-bones > > > > > implementation (one event class) that is fast and light. The > > > 'rich' > > > > > package defines an event hierarchy (with AddEvent, RemoveEvent > > > etc.) > > > > > that tracks all delta data necessary to reconstruct a > > > collection's > > > > > entire history. In particular, RichCollectionEvent implements > > > > > ReplayableEvent (see below). The 'monolithic' event package is > > > (like > > > > > 'rich') a heavyweight package that implements ReplayableEvent, > > > but > > > > > has > > > > > only one event class (MonolithicCollectionEvent) instead of an > > > > > hierarchy. This package is an implementation of the > > > > > Heuer/mailing-list > > > > > design that we discussed some time ago, and is basically intended > > > as > > > > > a > > > > > dis-proof-of-concept. I will discuss this in a follow-on email. > > > > > > > > > > Probably the most interesting new feature is the > > > "ReplayableEvent" > > > > > interface. This interface defines two methods, #replay and #undo > > > (may > > > > > rename), and is implemented by the 'rich' and 'monolithic' > > > package. > > > > > An > > > > > example of usage is below. > > > > > > > > > > > > > > > ############################# > > > > > > > > > > class MyListener implements CollectionListener > > > > > { > > > > > CollectionEvent event; > > > > > > > > > > public void collectionEventOccurred(CollectionEvent event) > > > > > { > > > > > this.event = event; > > > > > } > > > > > } > > > > > > > > > > NotifyingList nl = NotifyingCollectionsUtils.notifyingList(new > > > > > ArrayList()); > > > > > > > > > > MyListener listener = new MyListener(); > > > > > nl.addCollectionListener(listener); > > > > > > > > > > String s = "hello"; > > > > > > > > > > nl.add(s); > > > > > assertTrue(nl.size() == 1); > > > > > > > > > > AddEvent event = (AddEvent) listener.event; > > > > > assertTrue(event.getAddedItem() == s); > > > > > > > > > > // now for the fun part > > > > > event.undo(nl); // undoes the add action > > > > > assertTrue(nl.size() == 0); > > > > > > > > > > // replay the action > > > > > event.replay(nl); > > > > > assertTrue(nl.size() == 1 && nl.contains(s)); > > > > > > > > > > // replay the action on a different target > > > > > List list = new ArrayList(); > > > > > > > > > > event.replay(list); > > > > > assertTrue(list.equals(nl)); > > > > > > > > > > ############################ > > > > > > > > > > More comments in follow-on email. > > > > > > > > > > Neil > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: > > > [EMAIL PROTECTED] > > > > > For additional commands, e-mail: > > > [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > For additional commands, e-mail: > > > [EMAIL PROTECTED] > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
