a 'doc' field value -- ideas?
Will Partain <[email protected]> Fri, 24 Aug 2001 21:23:45 +0100
| Newsgroups | gmane.comp.sysutils.ark.devel |
|---|---|
| Message-ID | <[email protected]> |
Context: an ARK world is made up of "things" (hosts,
packages, vendors, users, ... what-nots) [each represented
by an XML file], each simply being a collection of "fields"
(ip-addresses, fstab, ... for hosts; surname,
favorite-ice-cream, ... for users; and so on) [each
represented by an element in XML]. Though what fields a
thing has is almost entirely up to you, what comprises a
field is *the same* across the board (params, constraints,
and ... a value). [It's crazy, but it works :-)]
At present, a field can have one of four kinds of value: a
string (very common), a table, a list, or a "code" (a
fragment of scripting that can be run, printed, pawed over,
...).
I'm proposing a *fifth* kind of a value, a "doc", being "a
fragment of documentation". A <doc> would be a splodge of
text, plus a bunch of properties, possibly including
"format" (plain text, HTML, XML, texinfo, ???), "language"
(as in English, French, etc.), "view" (user, sysadmin), and
who knows quite what. So you might have:
<description><doc view="user" lang="en">
This thing slices and dices.
</doc></description>
<description><doc view="user" lang="en" format="bad-html">
This thing <blink>slices and dices</blink>.
</doc></description>
<description><doc view="sysadmin" lang="fr">
Je ne suis pas dan la salle a manger.
</doc></description>
My initial thought about the (Python) programming API,
i.e. what you get when you type
descr = thing.description()
is that 'descr' will return a list of pairs, the pair being
the text and a hash of the properties. Thus,
print `descr`
would give (pardon my python)
[ ('This thing slices and dices'
, {'view': 'user', 'lang': 'en'})
, ('This thing <blinks> and ...'
, {'view': 'user', 'lang': 'en', 'format': 'bad-html'})
, ('Je ne suis...'
, {'view': 'sysadmin', 'lang': 'fr'})
]
It's up to the caller to know what to do with this; we would
presumably supply utility routines for common grokking
patterns.
Anyone with any thoughts? (I am planning that the next
mini-iteration of the webware stuff will use this)
Will