Lex Trotman wrote:
On 14 March 2010 10:50, Stuart Rackham <[email protected]
<mailto:[email protected]>> wrote:
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
Yes, reproducability is a key requirement of a document processing
system. Otherwise a document can't be saved in source form and
re-created later If output can't be created from the source in the
future then documents are stuck with the output formats that can be
generated today, but they may not be readable in future. Instead the
system needs to support generating output for a current format but using
the input from the past.
So, its vital that a document processing system continue to be able to
process old documents (and get effectively the same output, albeit with
a different target).
Cameron's approach will immediately stop asciidoc working with any older
document that used a custom config file, but the incremental approach
will remain backward compatible.
@Tong, nice as the programming paradigms you quote are, they simply
don't address the situation of a program that has been in use for many
years and has a large collection of existing source. They must remain
backward compatible since its not feasible to require all users to
update their input to a new format.
This is required reading for anyone considering rewriting and replace existing
code:
http://www.joelonsoftware.com/articles/fog0000000069.html
Cheers, Stuart
Cheers
Lex
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]
<mailto:[email protected]>> wrote:
On Mar 13, 1:42 am, Lex Trotman <[email protected]
<mailto:[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]
<mailto:[email protected]>.
To unsubscribe from this group, send email to
[email protected]
<mailto:asciidoc%[email protected]>.
For more options, visit this group at
http://groups.google.com/group/asciidoc?hl=en.
--
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.
--
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.
