commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne" <scolebou...@btopenworld.com>
Subject Re: [collections][submission] NotifyingCollections
Date Thu, 24 Jul 2003 20:27:26 GMT
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" <neilotoole@yahoo.com>
> --- Stephen Colebourne <scolebourne@btopenworld.com> 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" <neilotoole@yahoo.com>
> > To: "Jakarta Commons Developers List"
> > <commons-dev@jakarta.apache.org>;
> > <neilotoole@users.sourceforge.net>
> > 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 <neilotoole@users.sourceforge.net> 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:
> > commons-dev-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail:
> > commons-dev-help@jakarta.apache.org
> > > >
> > >
> > >
> > >
> > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail:
> > commons-dev-help@jakarta.apache.org
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message