On 14 March 2010 10:50, Stuart Rackham <[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. 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]> 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]<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.
