Phillip Lord wrote:
Stuart Rackham <[email protected]> writes:
cweagans wrote:
Yeah, so basically, my idea was to completely replace the entire idea
of the .conf files. I think that with the system I'm proposing,
there's no reason to keep them around anymore.
A safer incremental approach would be to make templates optional. Put them in
per backend directories named like templates/<backend>/ and name them the same
as the current .conf file entries.
I think the cascading nature of the conf files is going to be hard to
replicate.
Multiple template files could be read using similar conventions to .conf files
with a bit of introspection to override repeated functions.
If you split asciidoc into two halves, parse and output, though it might
work. The default output class would be essentially what you have now,
but factored out and separate from the parse step. By default, it would
read from the conf files, but the user would be able to override this
behaviour by writing python code.
This would then allow configuration with either .conf files or python
code. You could override as much or as little as you choose.
Exactly.
The hard bit would be getting the interface between the two correct;
but, it think it would be a better design than having the output code
full of "if there is a .tpl file do that, otherwise do whatever the
.conf says". It seems to be replicating facilities that python already
provides.
There are only one or two place that would need to be modified with this code
(see my previous post).
Cheers, Stuart
I agree, in general, though the only way to keep backward compatibility
is to support both mechanisms.
Phil
--
You received this message because you are subscribed to the Google Groups
"asciidoc" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/asciidoc?hl=en.
