commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne" <scolebou...@eurobell.co.uk>
Subject Re: [Collections][SUBMIT] TypedList - FilterList
Date Wed, 24 Apr 2002 20:23:26 GMT
Please find attached the code for FilterList. This permits both
transformation and validation:
/**
 * FilterList is a list wrapper that supports validation and transformation
 * of <em>input</em> into the list.
 * All objects to be added to the list are first transformed, and then
 * validated. Either of these steps may throw an
<tt>IllegalArgumentException</tt>.
 * <p>
 * The transform step could be used to type convert objects on list entry,
 * for example to convert String objects to Integer objects. The validation
 * step could be used to ensure that the list does not contain nulls, or
 * that only instanceof of a particular class are allowed. The mechanism
 * for both is a plugin interface - <tt>Predicate</tt> for validation,
 * <tt>Transformer</tt> for transformation.
 * <p>
 * The common case of validating for an instanceof a particular class
 * (or subclass) is available by using the <tt>getTypeCheckedList</tt>
 * static factory method.
 * <p>
 * By default, this class will use an ArrayList behind the scenes.
 * Alternatively, a List implementation, such as <tt>LinkedList</tt>, may
 * be wrapped by the constructor.
 *
 * @author Stephen Colebourne
 */

Feedback welcome. If this is agreed as an acceptable final design, and there
is demand, I will code up Map and Set variations.

Stephen

From: James Strachan <james_strachan@yahoo.co.uk>
> I agree Stephen. I like the simple approach of just having a Predicate -
> nice and simple. Also I don't quite see how/why we'd want different
> Predicate & Transformer operations based on which methods we're calling on
> the collections (adding/removing/getting etc). This more complex approach
> probably requires different collection implementations.
>
> Though having an optional Transformer applied to objects being
added/removed
> might be useful too. e.g. this approach would make it easy to allow type
> coercion into Strings or Numbers if required or to use interning to
promote
> object sharing . I guess in this case the transformer should fire first
and
> the predicate second?
>
> Also I like Henri's idea of using the 'Filter' name/concept as in Servlet
> Filters. Then we could have FilterList that can have a Predicate and/or a
> Transformer for doing simple transforms to objects as they get
added/removed
> to the list as well as filtering out bad objects.

I'm concentrating on the add operations.

> After reading (part of) Joshua Block's Effective Java (which I'll finish
> eventually, its a great book!), in the scenario of adding an invalid
object
> we should probably throw an exception, reusing one from the JDK.
> java.lang.IllegalArgumentException is probably the one to use. Thoughts?

It does throw an IllegalArgumentException.

>
> James
> ----- Original Message -----
> From: "Stephen Colebourne" <scolebourne@eurobell.co.uk>
> To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
> Sent: Tuesday, April 23, 2002 10:46 PM
> Subject: Re: [Collections][SUBMIT] TypedList
>
>
> > OK, this is a different design to one using Predicate, although
obviously
> a
> > similar purpose. Before I can continue and finish the other collections,
I
> > would like a decision on which way to go ;-)
> >
> > This design gives much more power, but is therefore more complex (more
> > methods, more choice). Maybe there is a case for both. Maybe there is a
> case
> > for wrapping a Predicate in a CollectionFilter. Not quite sure yet.
> >
> > I would suggest the following interface is necessary to fully express
the
> > possibilities:
> > public interface CollectionFilter {
> >   // predicate
> >     public boolean allowUpdate(Object obj, Collection coll);
> >  // transform
> >     public Object beforeUpdate(Object obj, Collection coll);
> >  // info
> >     public void afterUpdate(Object obj, Collection coll);
> >
> >   // predicate
> >     public boolean allowGet(Object obj, Collection coll);
> >  // info ???
> >     public void beforeGet(Object obj, Collection coll);
> >  // transform
> >     public Object afterGet(Object obj, Collection coll);
> >
> >   // predicate
> >     public boolean allowRemove(Object obj, Collection coll);
> >  // ???
> >     public Object beforeRemove(Object obj, Collection coll);
> >  // ???
> >     public Object afterRemove(Object obj, Collection coll);
> >  }
> >
> > Hmm. Having sketched that out, I think I'm tending towards keeping it
> simple
> > and sticking with PredicateList and TransformList. Views? I need
guidance
> on
> > this one before I can continue.
> >
> > Stephen
> >
> > From: Henri Yandell <bayard@generationjava.com>
> > > public interface CollectionFilter {
> > >
> > >     public Object beforeAdd(Object obj, Collection coll);
> > >
> > >     public Object beforeRemove(Object obj, Collection coll);
> > >     public Object afterRemove(Object obj, Collection coll);
> > >
> > > }
> > >
> > >
> > > And same (ish) for Map? And then List/Set extend Collection filter and
> add
> > > events?
> > >
> > > When something is added to the collection, it checks with beforeAdd,
> > > passing the object and the collection. In TypedFilter it is set to
only
> > > allow Strings. It finds out the object isn't a String and returns
null?
> > >
> > > But does that mean return or insert null. Can we have an interface
that
> > > means both Predicate and Transform?? Or should they be separate.
> > >
> > > Hen
> > >
> > > > So we need something more than the existing Predicate/Transformer
> > classes
> > > > then? I think I need to go and code something to it working...
> > > > Stephen
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> > <mailto:commons-dev-unsubscribe@jakarta.apache.org>
> > > For additional commands, e-mail:
> > <mailto:commons-dev-help@jakarta.apache.org>
> > >
> > >
> >
> >
> > --
> > To unsubscribe, e-mail:
> <mailto:commons-dev-unsubscribe@jakarta.apache.org>
> > For additional commands, e-mail:
> <mailto:commons-dev-help@jakarta.apache.org>
>
>
> _________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
>
>
> --
> To unsubscribe, e-mail:
<mailto:commons-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
<mailto:commons-dev-help@jakarta.apache.org>
>
>

Mime
View raw message