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. 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. 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. 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.
