In article <C44EE7B289BF4C3D90EC146B0B9529C2 at ANTONIOPC>,
<arcarlini at iee.org> writes:
I can no doubt find some simple way of coming up with
all the fields.
A simple awk script should be able to it. (Or pick your poison if you
don't like awk.)
I gathered this stuff over a number of years. As
it's a bunch of mildly
formatted text files, it's not terribly consistent. Plus many fields for
(say) VAX are not applicable to (say) disks.
There are a number of ways you can handle that in mediawiki.
You can create specialized templates for VAX (my preference), or you
can add conditional logic in the template "if this field present, then
these other fields are relevant".
My 20s spent looking at
media wiki templates suggests that you feed each template a bunch of
parameters, the same set everywhere a template is used. How does that
work if you want people to come along and edit an entry later?
The template only handles formatting, not content. The content is the
set of supplied arguments to the template. For instance, on the
terminals wiki, I have templates that create the summary infobox on
the right hand side for each terminal. When you edit the page, you
see the template call in the page with all the arguments that define
the content.
If you want to edit the presentation of the content, you edit the
definition of the template itself.
For fancy things like infoboxes, there is a small amount of CSS you
also have to edit in wikimedia.
For
example, if you have data for 20 or so different VAX systems and only
then realise that you've completely forgotten about the "Compatibility
mode" property. You can add it to the template, but do you need to go
back and change every template invocation to add the new parameter?
There are two ways of handling this. One is to supply a reasonable
default (usually empty) for the template parameter in the definition
of the template. You only create presentation for parameters that are
non-empty when the template is called. Old calls to the template that
don't supply this new parameter render the same. New content appears
for any calls to the template that supply the new parameter.
If you've decided that the new parameter must be supplied, and there
is no reasonable default, then you do a search for all the existing
uses of the template and add the parameter first. (Unused parameters
are ignored when the template is processed.)
Then you add the presentation for the new parameter in the template.
The new content will just show up for the existing calls to the
template. You can go further and add error handling to the template
to call out missing required arguments. I do this for the terminals
wiki infobox -- if required parameters are missing, or have the wrong
values, then the entire infobox is omitted and you just get a big red
error message on the page. It's pretty obvious when the template
isn't used correctly that way.
I should point out that the [CU-V6-5A] part is a
"reference" field. That
one happens to be "Customer Update. Volume 6 Issue 5A. 1st May 1995".
When I turned some of this into webpages then that ended up as "[1]",
"[2]" etc. and the references were spelled out at the foot of the page.
You might want to make provision for that so that future page editors
have some guidelines to follow.
I believe this references mechanism can also be handled in mediawiki markup.
--
"The Direct3D Graphics Pipeline" free book
<http://tinyurl.com/d3d-pipeline>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
The Terminals Wiki <http://terminals.classiccmp.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>