Hi Kalle, I'm going to take a stab at refactoring the configuration classes this weekend as discussed previously (maybe a month ago?) to use composition instead of inheritance. It will still be .ini-based pending more feedback on this thread, but it should alleviate the problems you had with all that custom coding.
Cheers, Les On Sat, Apr 4, 2009 at 5:21 PM, Kalle Korhonen <[email protected]>wrote: > +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. > > >
