Joel de Guzman <[EMAIL PROTECTED]> writes: > Jeff Garland wrote: >> Joel de Guzman wrote: >> >>>> Or is this already possible with the template mechanism in some other >>>> way? >>> That's a perfect job for Python! :) I guess we should provide a >>> boost python wrapper support for accessing the parser state info. >>> This is Dave's wish list and I intend to pursue it along these >>> lines. Python will have access to the "collectors", the (soon >>> to be) "code stacks", filenames, symbol tables, etc. Then, in >>> Quickbook, we can pass info to and from Python. >> >> Sorry to be a stick in the mud, but please don't increase the Quickbook >> tool chain by adding Python to perform basic functions that don't >> require it now. > > Understood. As I see it, the basic std.qbk library should not require > any scripting. I think there should be a way to enable scripting only > when needed. IOTW, the user should not pay for things s/he does not > need. With that restriction, templates should still simplify quickbook > code to about 10-20% its current size. > > Pardon me if I wasn't clear with my reply to Dan. The [heading] markup > will not be a template (again, basic std.qbk library should not require > any scripting). What I meant is that if someone wants to add some user- > markup that does something similar to [heading], it would (as I imagine) > have to be through a scripting interface.
Sorry, but I really disagree with this approach. In a sense, the biggest reason for the mess that is the current Qbk toolchain is the lack of Python. There's no reason for us to go through docbook and XSLT in order to generate HTML pages (or PDF, for that matter -- LaTeX is a much more reliable path to good PDFs than FOP is, and it will be so for some time, AFAICT). Here's how it works in docutils: the front-end parser builds an AST/DOM (in Python of course -- a much better language for ASTs than C++ because of their very dynamic structure). The various back-end translators (also written in Python) are simply SAX-like visitors that generate "events" for the entry and exit of the various AST nodes. So when entering the "table" node, the translator's visit_table method (if any) is called, and when leaving, its depart_table method is called. The code for translating the DOM into HTML, LaTeX, or any number of other formats they already have support for is surprisingly straightforward and maintainable. With a system like this, if we wanted to write a Qbk->Docbook translator in addition to the Qbk->HTML translator it would be simple. -- Dave Abrahams Boost Consulting www.boost-consulting.com _______________________________________________ Boost-docs mailing list [email protected] Unsubscribe and other administrative requests: https://lists.sourceforge.net/lists/listinfo/boost-docs
