From: Brian I. <in...@tt...> - 2003-02-24 18:56:28
|
On 24/02/03 19:10 +0100, Michel Rodriguez wrote: > Hi Ingy, > > I like YAML for configuration file... except that it lacks a feature > that would make my life much easier: variables. This could not be a part of the YAML language itself of course, but a YAML Loader is free to Load a scalar as it sees fit. For instance a Loader could be configured to load '0x1a' as the number 26 or as the string "0x1a". (or as anything else, but that wouldn't be sane) So there is no reason why a loader couldn't be configured to do what you want. The question is where to put the code. It's unlikely that I'll support this directly in YAML.pm. But I should add a callback mechanism that would allow you to modify scalars as they were being loaded. > I'd like to be able to write: > > --- #YAML:1.0 > dir: > web: '/web' > cgi: '$web/cgi-bin' > cgi_dict: '$cgi/dict' > include: > - '$cgi_dict/lib' or more elegantly, (given a more elegant YAML.pm) --- dir: web: /web cgi: $web/cgi-bin cgi_dict: $cgi/dict include: - $cgi_dict/lib > > And have the option to resolve the variables. So the new YAML.pm might allow you to do this: $YAML::LoadScalar = \&yaml_variables; my $config = YAML::LoadFile('config'); my %symbol_table sub yaml_variables { my ($scalar, $key) = (@_, ''); $scalar =~ s/\$(\w+)/$symbol_table{$1}/; $symbol_table{$key} = $scalar if length $key; return $scalar; } > I can post-process the structure loaded by Load, but then it is quite a > pain because hashes are un-ordered. > > The best place to do this would be during the parsing, as then I would > get everything in the right order, without forward references. > > Would it make sense to write a modified Load (or to add options to Load) > to do this? I guess probably not, as then this would not be YAML > anymore. > > Do you have any idea how best to add this? > > I can probably write a patch if it makes sense. A cursory look at the > code shows that _parse_inline_mapping could be modified to handle this, > does it make sense? You could write a patch, but I would just do it for yourself until I can get the next release of YAML.pm out the door. I'll be sure add a hook like this. Cheers, Brian |
From: Clark C. E. <cc...@cl...> - 2003-02-26 05:15:32
|
Neat. On Mon, Feb 24, 2003 at 10:56:07AM -0800, Brian Ingerson wrote: | --- | dir: | web: /web | cgi: $web/cgi-bin | cgi_dict: $cgi/dict | include: | - $cgi_dict/lib A $$ would be nice to let you know what the parent-key is... list-of-people: 2939: id: $$ # short for 2939 name: Clark 9393: id: $$ # short for 9393 name: Brian I find this pattern alot, I want to use an ID as the key, but yet, I want to store the key in a mapping. I'd like a nice short-cut syntax for this, it need not be in yaml-core... the $ variable substution thingy above is quite cool though. ;) Clark |
From: Michel R. <mi...@xm...> - 2003-02-26 16:34:51
|
On Wed, 2003-02-26 at 06:30, Clark C. Evans wrote: > Neat. > > On Mon, Feb 24, 2003 at 10:56:07AM -0800, Brian Ingerson wrote: > | --- > | dir: > | web: /web > | cgi: $web/cgi-bin > | cgi_dict: $cgi/dict > | include: > | - $cgi_dict/lib > > A $$ would be nice to let you know what the parent-key is... > > list-of-people: > 2939: > id: $$ # short for 2939 > name: Clark > 9393: > id: $$ # short for 9393 > name: Brian > > I find this pattern alot, I want to use an ID as the > key, but yet, I want to store the key in a mapping. > I'd like a nice short-cut syntax for this, it need > not be in yaml-core... the $ variable substution > thingy above is quite cool though. It doesn't look like you can get thais in the current implementation of the Perl module: the YAML object does not expose the parent key when the loader is called. It does not look like a big deal to store the stack of keys in the object though. I have a patch that does just that BTW, if you want it Ingy (or should I send you its spirit? ;--). It might be smarter to allow callbacks when keys are recognized though, that would be a little more generic (it would allow you to manage scopes for variables for example). -- Michel Rodriguez <mi...@xm...> |
From: Oren Ben-K. <or...@be...> - 2003-02-25 18:24:20
|
Now that we have allowed plain scalars to start on the next line, it seems we can remove the restriction that a document without a header can't be a (plain) scalar. That is: --- This is a valid document ... And hence # --- This can also be one ... Originally we disallowed this due to a possible ambiguity with a header-less mapping document, but this is no longer an issue due to the new (well, not that new now :-) plain scalar rules. After all, the same ambiguity issues occur when writing: --- Key: Next line plain scalar ... If that works, so (should) the above. Thoughts? Have fun, Oren Ben-Kiki |
From: Oren Ben-K. <or...@be...> - 2003-02-25 18:24:20
|
Now that we have allowed plain scalars to start on the next line, it seems we can remove the restriction that a document without a header can't be a (plain) scalar. That is: --- This is a valid document ... And hence # --- This can also be one ... Originally we disallowed this due to a possible ambiguity with a header-less mapping document, but this is no longer an issue due to the new (well, not that new now :-) plain scalar rules. After all, the same ambiguity issues occur when writing: --- Key: Next line plain scalar ... If that works, so (should) the above. Thoughts? Have fun, Oren Ben-Kiki |