On Sat, Apr 4, 2009 at 3:22 PM, Les Hazlewood <[email protected]> wrote:
> 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. > Thanks. I wouldn't consider it a problem though apart from not being able to use any common super classes. Configuring things programmatically fits to Tapestry style better anyway, so I'm not going back to the ini files, but I plan on keeping the implementation up-to-date with Ki and taking of new common code whenever appropriate. Kalle 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. > > > > > >
