Damn blogger just ate about 15 minutes of work writing up this idea I
had. I'll recapitulate the key points here.
I'm really envious of how Needle (IoC/DI for Ruby) doesn't need any
external configuration. It's all done with Ruby blocks. You provde a
block to Needle that gets executed when you need an instance of the
service. Very simple.
HiveMind uses too much XML (right, Erik?). What I realized very
explicitly a few months back, was that <invoke-factory> & friends are
just a verbose, declarative scripting language. Same goes for Spring.
So I had an idea for an alternate way of getting objects instantiated,
that borrows from the Ruby approach. This is an addition to the
traditional HiveMind (XML) approach.
Say for every module, there's an associated class that gets instantated.
We use some naming conventions to identify which public methods are
used to instantiate a service. We then implicitly define a service
point for that service. I pictured something like:
public class ValidServices
{
public ValidatorBindingFactory
newValidatorBindingFactory(ObjectResolver resolver)
{
ValidatorBindingFactory result = new ValidatorBindingFactory();
result.setValidatorBeanFactory((ValidatorBeanFactory)resolver.getService("ValidatorBeanFactory"));
result.setValueConverter((ValueConverter)resolver.getService("tapestry.coerce.ValueConverter"));
return result;
}
}
You would have many newXXX() methods on a single class. There may be
additional metods for defining the service model. HiveDoc would be
"aware" of this as well, and would integrate these service points in
with all the others defined in XML (the service description could come
from the module's message catalog). Possibly there could be an
additional constructor that is passed a Module, and can do some
caching of common services.
As opposed to Ruby, the Java typing does kind of get in the way, so
this ends up being a bit more typing than even the XML. However, it
does get the services implemented with less XML and less Java
reflective access. You do lose autowiring.
So ... how much do we hate XML? I think HiveMind is pretty spot-on
for the configuration side of things, but for services, maybe a little
more code is a good thing?
--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind
Professional Tapestry training, mentoring, support
and project work. http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
