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.
Here are a couple of examples:
templates/xhtml11/footer.py (if present) would override the existing
xhtml11.conf [footer] section.
templates/docbook/listtags-qanda__term.py (if present) would override the
existing docbook.conf [listtags-qanda] section term tag entry.
This scheme is straight forward and transparent and would minimize disruption of
the existing codebase. Plus it would guarantee compatibility with the existing
implementation -- initially no templates would ship with the distribution, the
template mechanism would simply be available as an (optional) alternative user
customization option.
I'm very much against replacing the current .conf files, they must remain the
primary configuration mechanism.
Cheers, Stuart
For overrides of the built in output formats, I think that we could
implement a 'sub-theme' idea (again, borrowing from Drupal here).
Basically, in the conf file for an output handler, you could tell
asciidoc 'This output handler (my_xhtml) is going to be an override of
this other output handler (xhtml). So asciidoc would use all of
the .tpl files from the xhtml output handler, unless there was one
with a matching name inside my_xhtml (this way, I could
override...say....all the h1 markup).
That's also my reasoning for having it split into separate files. It's
a lot easier to selectively override elements of a document, IMHO, if
they are in separate files (not having to deal with figuring out why
data structure x doesn't contain the information that you think it
should)
On Mar 13, 9:04 am, Tong <[email protected]> wrote:
On Mar 13, 1:42 am, Lex Trotman <[email protected]> wrote:
To me the latter seems a less intrusive approach and it allows the extra
facility to be turned off if required (Stuart, my security concerns and
Murphys law both require the ability to turn it off, no matter how
transparent the changes are :-)
I would rather like to see the straight up / unify of the backend
output mechanism *in the end*, because
- There is one (extreme) software development philosophy which
requires that if you add something, then you should remove something
as well, to prevent bloatware. So far, adding another layer on top of
template sections and tag entries should only be a temporarily
solution.
- The current Agile practices, especially Test Driven Development
(TDD),http://en.wikipedia.org/wiki/Test_Driven_Development, will
ensure precisely backward behaviour compatibility. Since the project
Cameron is working on is institute funded, not a temp hack, I have a
feeling that Cameron would do extensive testing. Would you Cameron?
--
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.
