From: Robert Klemme <shortcutter@...>
Date: 2007-07-27T05:35:01+09:00
Subject: Re: Modeling -- how to support multiple views of same components?

On 26.07.2007 21:18, Trans wrote:
> 
> On Jul 26, 10:55 am, Robert Klemme <shortcut...@googlemail.com> wrote:
> 
>> Can you disclose more detail?
> 
> Sure. It's for configuration information. On the one hand, I want to
> be able to read package settings from a file that is strictly
> dedicated to packaging. So, for instance my project might have
> a .package file that has basically:
> 
>   project: foo
>   version: 1.1
>   dependencies: [ facets ]
>   formats: [zip, tgz, gem]
> 
> However, I also want to support an uber-project configuration file,
> that would look like:
> 
>   project: foo
>   version: 1.1
>   package:
>     dependencies: [ facets ]
>     formats: [zip, tgz, gem]
> 
> So I have two slightly different formats that I want to support with
> strict classes. Eg. in the first case:
> 
>   pkg = Package.load(file)
>   pkg.project #=> 'foo'
>   pkg.formats #=> ['zip','tgz','gem']
> 
> and in the other:
> 
>   pkg = Project.load(file)
>   pkg.project #=> 'foo'
>   pkg.package.formats #=> ['zip','tgz','gem']
> 
> So, the same info, but organized in the two different manners, as I
> described in the original post.
> 
> Note, by "strict class" I mean I'm not just keying off a YAML-loaded
> hash. I need a class b/c various attributes have default values,
> validation and formating applied, plus supporting methods.

So as far as I can see you have these requirements:

1. reuse of config parameters and their defaults in multiple places

2. default values for config parameters

3. supporting functionality (whatever that is)

Some random thoughts (as I'm pretty tired already): Personally I'd limit 
3 to a bare minimum.  I am sure there are multiple ways to handle 
default values (for example, using a template of nested Hashes and 
merging that with something parsed from the config file).  OpenStruct or 
a similar concept might come in handy.  Is validation of config values 
better done in (generic?) config classes or in application classes (I 
tend to believe the latter, because ensuring proper arguments is a task 
of the model).  Hm...  Probably not too useful.  Maybe I have more ideas 
after sleeping. :-)

Kind regards

	robert