Sounds good, I'll post updates to the list. Cheers,
Les On Sat, Apr 4, 2009 at 7:33 PM, Kalle Korhonen <[email protected]>wrote: > 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. > > > > > > > > > >
