I thought of this while working on the new Panorama example code.
A sizable chunk of code in the service exists to get the contributed
tasks into the right order, based on pre- and post-requisites:
public void run()
{
Orderer orderer = new Orderer(_log, _errorHandler, task());
Iterator i = _tasks.iterator();
while (i.hasNext())
{
Task t = (Task) i.next();
orderer.add(t, t.getId(), t.getAfter(), t.getBefore());
}
List orderedTasks = orderer.getOrderedObjects();
int failures = 0;
long startTime = System.currentTimeMillis();
i = orderedTasks.iterator();
while (i.hasNext())
{
Task t = (Task) i.next();
if (!execute(t))
failures++;
}
long elapsedTime = System.currentTimeMillis() - startTime;
if (failures == 0)
_log.info(success(orderedTasks.size(), elapsedTime));
else
_log.info(failure(failures, orderedTasks.size(), elapsedTime));
}
Seems to be, it would be nicer if the _tasks instance variable was
assigned the ordered list, not the unordered list. By telling the
schema for the configuration how to order the elements, this can be
done, further simplifiying the code inside a service.
Seems to me, that by adding *something* to the MDD, this ordering
could take place in concert with the construction of the list.
On Sun, 25 Jul 2004 10:16:20 -0300, Marcus Brito <[EMAIL PROTECTED]> wrote:
> Could you come up with a use case where manual configuration ordering
> would add some value? I didn't get it. If the user configuration is
> strongly typed, with well defined property names, ordering doesn't
> make sense. If the user configuration is just a bunch of values, we
> should use the same order the elements were specified in the
> descriptor. Principle of least surprise, I think.
>
--
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]
