On Fri, Jan 31, 2014 at 04:30:33PM +0100, Nathan Cutler wrote: > * Configuration. App::CELL's configuration model is inspired by Request > Tracker. An App::CELL configuration file is actually a Perl module (written > as a series of calls to a 'set' function) that is loaded using 'require'. > Not only does this leverage Perl itself to do the parsing -- it provides > great flexibility when it comes to defining configuration parameter values: > they can be scalars, or they can be references to anonymous arrays, > hashes, or subroutines. > > Maybe there's already a Config:: module that takes this approach, and I'm > just not aware of it?
Not really. The usual approach to format-agnostic configuration is Config::Any which allows you to have a perl file returning a data structure. Personally I'm not fond of perl for configuration unless the config files are to be written by developers and ignored by sysadmins, which tends not to be what I use config files for. > When an error occurs, it "bubbles" back up the stack and can be handled > wherever convenient. > > Can you point me to an existing module that does this? No, because it's a terrible idea. Whst the linked article doesn't discuss is the fact that the try/catch approach allows you to run a sequence of methods and trap errors from all of them in a single block, at which point the try/catch based approach is much less code. Try::Tiny::ByClass would be a nice approach to structured exception catching, and if you want to be able to resume or return *optionally* when errors occur then look at Worlogog::Incident and Worlogog::Restart. Using the latter two would allow users who want to do things the standard way to continue to do so, and you to use your own approach internally. I still think it's a terrible idea, but I entirely support your right to do so, especially if I can still get exceptions :) > * Logging. App::CELL implements a simple logging mechanism (Log::Fast- > based) that is integrated with CELL::Message objects. You are right that > this could be perceived as an attempt to force people to use my logging > mechanism instead of their preferred way. On the other hand, the > configuration, error-handling, and i18n functions _need_ to log. So I > guess I will need to provide a way for folks to overlay App::CELL's > logging functions with their own. Look at Log::Any as a way to allow use of arbitrary logging systems. -- Matt S Trout - Shadowcat Systems - Perl consulting with a commit bit and a clue http://shadowcat.co.uk/blog/matt-s-trout/ http://twitter.com/shadowcat_mst/ Email me now on mst (at) shadowcat.co.uk and let's chat about how our CPAN commercial support, training and consultancy packages could help your team.
