+1. For the same reasons and more, I've implemented a programmatic JSecurity/KI configuration for Tapestry5 (and in doing so, bypassing many of the base classes meant to be used in Ki). Besides the clutter of describing an object graph in a property file, the default implementation didn't AFAIK support using multiple ini files. I might re-consider using configuration files if the implementation would support loading them from multiple locations and merging the configuration.
Kalle On Sat, Apr 4, 2009 at 12:25 PM, Les Hazlewood <[email protected]>wrote: > As most of you know, Ki's default configuration format is .ini. We > basically use it like a properties file, but naturally the section headers, > ala [someName], provide context of how to apply the next block of > properties. > > However I've been wishing for a long time, and have voiced it a couple of > times only in passing, that we could use something different - something > more efficient yet adequately expressive for defining configuration. > > With the exception of a [urls] section in our .ini files, pretty much > everything else is declared for the purpose of defining an object graph. > > I feel that .properties and .ini are pretty poor mechanisms for configuring > an object graph. They become even more verbose than XML since pretty much > every property configured requires its own line. XML is better when you > consider things like Spring's XML bean definition mechanism for object > graphs. But even then I don't like XML's verbosity and cluttered 'feel'. > Also, we naturally shouldn't create a required dependency on Spring just > for > a reasonable configuration mechanism. > > So, I've been doing some searching and out of many alternate text-based > configuration formats, I feel that YAML would probably fit that 'sweet > spot' > for our project for a simple and human readable, yet still very > 'declaration-efficient' format. It beautifully supports object graph > definitions, object references, circular dependencies, as well as general > scalar definitions (e.g. our urls section). > > For example, check this out: http://jyaml.sourceforge.net/tutorial.html > and this: http://yamlbeans.sourceforge.net/ > > Look at the yaml text compared to even normal Spring definitions. jyaml > even supports Spring-like configuration, without depending on Spring ( > http://jyaml.sourceforge.net/yaml4spring.html - very bottom of the page). > > After reasearching yaml and JSON and other formats, I feel that YAML has > learned tremendously from XML and resulted in a clean and easy to > understand > text-based format. Given its ease of use and understanding, yet expressive > capabilities, I feel this would be far better suited to our project for a > default config format over .properties or .ini. And we don't have to write > the parser/config mechanisms like we do with the .ini solution in place now > - we just depend on a 3rd party parser so there isn't much to maintain - > even better. > > What do you all think about using YAML as our default config mechanism for > 1.0 moving forward? > > - Les > > P.S. This goes without saying, but we should naturally allow end-users to > supply their own configuration - I'm just talking about what could be Ki's > default. >
