Howard,

On 5/6/05, Howard Lewis Ship <[EMAIL PROTECTED]> wrote:
> 
> 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.
> 

I second that. I think the recently added "conditional contributions"
feature is a good indication that scripting a registry is sometimes a
good alternative to a purely declarative definition.

> 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;
>   }
> }
> 
> 
> 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.
> 

Possibly the passed ObjectResolver could even do autowiring... E.g.
resolver.autowire(result);

> 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?
> 

I think this idea of letting a Java class implicitly define a module
is very interesting. I'm saying 'implicitly' because the definition is
based on some naming conventions and because the class has to be
registered and used as required by HiveMind. I think it would also be
very interesting to take a look at creating a Java API for explicit
(probably more verbose) module and service definition. This could then
hopefully also be used as the implementation for both the XML module
descriptors and this new style of Java module descriptors.

--knut

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to