[check] Status on HEAD... (Templates done, Config code up next)

Terje Bless <link@pobox.com> wrote:

>Ok, HEAD is merged and my template code just landed. Yay! :-)

And the Template code now passes all the text cases on /dev/tests/ so it's
more or less feature-complete compared to the stable branch, but still
needs massive stabilization work and the i18n framework is still AWOL.

However, to get complete i18n it's not enough to use the current template
code. We have at least 3 distinct areas that need to be i18n-ized. The
current template code takes care of the basics for the first, normal
output, and the two remaining are fatal error messages (which contain
hard-coded messages and markup) and onsgmls output.

The latter is still wide-open; there are several ways we could achieve it
with no clear deciding factor as yet, and is a massive amount of work. So
I'm going to leave this off for a while.

The fatal error handling will probably need real exception handling and a
gettext-ish i18n framework. This will also be usable for the i18n of the
normal output, which is why I've left that unfinished for now.

For this I have some more or less specific plans, but I need to look closer
at the alternatives (which i18n library) before they gel completely so I'll
get back to the specifics later.


All in all this needs to bake a while before I'm ready to continue. So...


...Next up is an overhaul of the configuration files and related code. This
will break HEAD in a similar manner as the Template code, but will give us
a more consolidated and uniform configuration, strip out a goodly bit of
hard-coded messages, enable some new features, and make it easier to add
new document types++ to the Validator.

Using Ville's Config::General code, I'm working on one unified config file
that specifies, for each known document type (e.g. HTML 4.01 Transitional),
the allowed Content-Types, the URI for the "Valid Foo" image, the FPI,
whether it should be parsed as XML or SGML, etc.

This will obsolete several of the config files that are basically lookup
tables and consolidate them into one single file (which is basically a
complex datastructure). It will also require some supporting code in
"check" to provide reverse mappings (e.g. from FPI to "pretty name" etc.),
but it should result in a net cleanup of the affected code and can cleanly
be moved into a module and hidden behind OO magic when we get around to
m12n the code.


Details left out for brevity; if anyone wants to play, ping me and I'll
write up something more specific on what I'm planning.


-- 
Of course we are the good guys! We define what is good and evil. All other
definitions are wrong, and possibly the product of a deranged imagination.
                                                         -- Stephen Harris

Received on Saturday, 7 December 2002 00:13:46 UTC