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.
[1] http://jakarta.apache.org/commons/sandbox/hivemind
[2] Digester - Commons
···
–
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”’