commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <craig...@apache.org>
Subject Re: [HiveMind] Re: Alternative module descriptors
Date Sat, 06 Mar 2004 20:58:07 GMT
Quoting Harish Krishnaswamy <hkrishnaswamy@comcast.net>:

> 
> 
> Craig R. McClanahan wrote:
> 
> >
> >Another approach for users who don't like hand-coding XML documents is a
> >purpose-driven GUI tool to edit the configuration file.  For example, James
> >Holmes has created such a tool (runs either standalone or as a plugin for a
> >bunch of different IDEs) for both Struts and JavaServer Faces configuration
> >files:
> >
> >  http://www.jamesholmes.com/struts/console/
> >  http://www.jamesholmes.com/JavaServerFaces/console/
> >  
> >
> 
> Hand-coding the xml configs is actually not my primary concern. Infact I 
> prefer to hand-code it (with context sensitive help ofcourse!) over 
> using a GUI. But it seems to me that a scripting language is more apt 
> for the kind of configuration that HiveMind does. In fact a lot of my 
> current configurations are actually OGNL statements that are simply 
> accumulated and provided to my service which executes them. It seems 
> rather silly to write all this XML to simply create a list of objects. 
> If a scripting language is used instead the framework becomes far, far 
> simpler for configuration management. None of digester style schema 
> specifications and parsing are required.
> 

As YAO (yet another alternative), if the person writing the configuration file
is skilled enough to understand how to write scripting language statements,
they can probably write a simple Java class to do the wire-up just as easily,
and not even bother learning a different language. :-).

That's a place where the pico guys (among other folks) got it right, in my
opinion ... containers should not dictate one-and-only-one configuration
mechanism.

> -Harish

Craig


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message