From: Jamis Buck Date: 2004-03-15T11:35:20+09:00 Subject: Re: YAML as configuration format why the lucky stiff wrote: > first of all, i'm not clear on the above example and i'd like to know > what you mean by the above. Sorry. I tried to condense a much-more complex real-life situation into a bite-sized example and it lost a lot of its relevancy. Let me try to just explain what I'm trying to do, and perhaps fish for some suggestions without any of my own biased implementations tainting them. I'm trying to implement an Apache Digester work-alike, in Ruby, using YAML instead of XML. (Actually, my ultimate goal is to create a Hivemind [1] work-alike in Ruby, using YAML for the configuration format, but the relevant portions of Hivemind I'm trying to tackle right now are concepts borrowed from the Digester project, etc, etc.) And I'm trying to do it without really understanding how the Digester library actually works. It's more of a "gee-that-sounds-like-a-great-idea, I-wonder-if-I-could-do-that-in-Ruby" kind of thing. So, I'm under-educated, feeling cocky, and dangerous with a Ruby interpreter. And I'm sitting here with a crazy idea that I should probably leave to better qualified individuals, only I imagine they're all busy with worthier projects (like a poignant guide or something). Thus, it falls to me. It's a great responsibility, but I'm proud to accept it, blah blah blah. So, if you're unfamiliar with the Digester, then you're not much behind my own level of familiarity with it. On the other hand, if you're an old hand at using the Digester libraries, just flash your battle scars in my direction and kindly point out any gross errors I'm making in my interpretation of it. According to my rapid scan of the Digester [2] website, the digester is for parsing XML configuration files. You define a schema of "rules", which map to rule objects, each of which has a well defined behavior. The rules operate on a stack, etc, etc. As XML, the tag name defines the name of the rule, with the attributes of the tag being rule-specific and (naturally) corresponding to different parameters of the tag. (I really, really hope I'm making sense, since this will be a pitiful waste of bandwidth otherwise.) So, you've got a sequence (ordered) of rules. Each rule is guaranteed to have at least a name. It may have other attributes, which will be rule-specific. In YAML (and I'm going off half-cocked again, knowing only enough YAML to be dangerous and incoherent): rules: - { name: create-object, class: PatientData } - { name: set-attribute, name: ailment, value: hemorrhoids } - { name: invoke-parent, method: push } The above psuedo-snippet would (given an arbitrary interpretation of the Hivemind-like rules used) instantiate PatientData and push the new object onto the stack. Then, it would set the "ailment" attribute of the topmost stack item to "hemorrhoids". Then, it would invoke the "push" method of the next-to-topmost stack element, with the topmost stack element as the parameter. Now, I've probably answered my own question here; when I posted the original message I didn't know about the {...} shortcut for defining a map, and was mildly sorry I couldn't define an entire rule on a single line (as above). That's what I meant when I said that YAML felt a little more awkward than XML. The one-line map definition certainly feels nicer to me. My question now is: is this an appropriate use of YAML? How could using "types" (which I am unfamiliar with in YAML) make this cleaner/better/easier? And lastly, is there a better way to represent data like this in YAML? I hope that was clearer than my original post. If it wasn't, or if more clarifications are needed anyway, I'll do my best to comply. Thanks for listening. - Jamis [1] http://jakarta.apache.org/commons/sandbox/hivemind [2] http://jakarta.apache.org/commons/digester/ -- Jamis Buck jgb3@email.byu.edu http://www.jamisbuck.org/jamis ruby -h | ruby -e 'a=[];readlines.join.scan(/-(.)\[e|Kk(\S*)|le.l(..)e|#!(\S*)/) {|r| a << r.compact.first };puts "\n>#{a.join(%q/ /)}<\n\n"'