This kind of ordering is based on dependency lists. Each object has a name, a list of its prerequisistes (objects that must come before it in the list) and postrequisistes (objects that must come after).
This is used, for example, to set the order in which interceptors are applied to a service. HiveMind used to rely on a numeric order, which was less than ideal. This approach is more flexible, if somewhat more verbose, since contributions can (it being HiveMind) come from all sorts of unexpected locations. On Mon, 12 Jul 2004 10:12:34 -0400, James Carman <[EMAIL PROTECTED]> wrote: > I'm not exactly familiar with the internal workings here, but from the names > of these classes and what you are saying, are we just trying to order some > objects in a collection of some sort? And, this collection needs to be able > to maintain the proper ordering as "things" are inserted into it? Then, why > can't you use a java.util.SortedSet along with some Comparator > implementations? Is there some weird requirement here that I'm missing? > > > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Monday, July 12, 2004 10:00 AM > To: [email protected] > Subject: leveraging Orderer > > Removing the dependency on Werkz (see issue HIVEMIND-6) mainly > encompassed rewriting oah.order.Orderer. While refactoring this class I > noticed that it is not related to (i.e. doesn't use) the oah.Orderable > interface. I think this could be redeemed by a further refactoring. > Also I was thinking if it would make sense to leverage Orderer by > providing it as a HiveMind service. > > Orderer is currently used to order two kinds of objects in HiveMind: > SymbolSourceContribution and ServiceInterceptorContribution objects. > The former is a class implementing Orderable and the latter is an > interface *not* extending Orderable. > > The interface of the Orderer class is given by the methods: > > public void add(Object object, String name, String prereqs, > String postreqs); > public List getOrderedObjects(); > > This means a client can't directly pass Orderable instances to the > Orderer. Instead the details of the object is passed and Orderer then > uses a local object to encapsulate these details again. > > IMO it would thus make sense to move the Orderable interface into the > oah.order package and use it as the single parameter to the add method > of Orderer. I.e. > > public void add(Orderable object); > > A benefit from this refactoring would be that the "intermediate" > non-public class ObjectOrdering could be dropped. Of course the client > ordering ServiceInterceptorContribution instances would have to use an > adapter (e.g. an anonymous class) to be compatible with the new > interface. > > Splitting Orderer into Orderer and OrdererImpl would let us publish it > as a service. > > Thoughts? > > Cheers, > > --knut > > --------------------------------------------------------------------- > 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] > > -- Howard M. Lewis Ship Independent J2EE / Open-Source Java Consultant Creator, Jakarta Tapestry Creator, Jakarta HiveMind http://howardlewisship.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
