Phillip Lord wrote:
cweagans <[email protected]> writes:
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)
You do have to find the correct files, though. We have had issues,
recently, with blogpost and getting hold of the relevant files that it
needs.
I'd also say that with the single file approach, you are limiting
yourself to the existing structure of the asciidoc. So, for example,
rewriting the asciidoc tree is not really possible -- stuff is going to
come out in the same order it went in. For example, recently I wanted to
make asciidoc go from...
Title
=====
:author: Phil
Abstract
--------
But to produce:
<title>Title</title>
<h1>Abstract</h1>
Stuff
<h1>Author</h1>
Phil
Which I don't think will work in your system. Finally, what happens if I
want to use a single function in several output layers. Then I have to
have do some sort of library function.
Basically, I think it would be much cleaner to have a single file (like
now), with "h1" and "h2" functions. Someone asked about the cascading
system that exists now, and how this would be replicated; you could now
achieve this with straight forward object inheritance. So, you would
have a class called "HTML4" and then another called "Wordpress" which
would just inherit from HTML4.
I think you are right about a single template file. The functions are not
backend specific though, asciidoc generates parses the source to a set of
predefined elements each of which has a (backend specific) .conf file template
(or tag). So the set of functions would be identical for all backends, just as
it is now e.g. instead of an 'h2' function there would be 'sect1' function
corresponding to the [sect1] template in the backend .conf file. My previous
post made the point that this scheme fits the existing model, requiring no
change to the way asciidoc parses the source. The rendering of node XXX becomes:
"if backend template function XXX exits then use it, else use the existing .conf
file XXX template (or tag)" -- there are only a couple of functions in
asciidoc.py that would need to be injected with this code.
I don't think cascading template files would be to difficult, but it's probably
not necessary.
Cheers, Stuart
In essence, you'd be building a "SAX-u-like" parser -- asciidoc would
parse the source, and call methods as things passed it's way.
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.
