|
From: Ben W. <da...@gm...> - 2007-06-09 20:20:10
|
I need to modify something I said. There is no need to use Python's
hashq I managed to reduce the sort to a nested array assignment.
On 6/9/07, Yuri Takhteyev <qar...@gm...> wrote:
> Ben, can you send us a more detailed explanation of your proposal?
I propose a different, flexible method for prioritizing markup
processing. This method has no effect on pattern matching/substitution
(i.e., processors); so the DOM method you're using remains intact.
While I personally prefer the string-to-string substitution, what is
proposed is agnostic to how markup is processed. So, what I propose is
a new organizer for the processors, not a new way to process.
For example, preprocessors are ordered in an array: self.preprocessor.
Postprocessors are likewise ordered. There are other similar
"buckets." If I wanted to insert a preprocessor between two standard
preprocessors (e.g. HTML_BLOCK, and LINE_BREAKS), then I have to
manipulate the array.
PmWiki's organizer is flexible. Each processor is named (dictionary or
associative array-based). Each processor announces when it should be
processed: before another processor, after another processor, or
generally within a processor group. For example, if STRONG must occur
before EMPHASIS, then we have:
p.register('strong','<emphasis,...)
If, alternatively, STRONG must occur _after_ EMPHASIS, then we have:
p.register('strong','>emphasis,...)
Finally, if we only want STRONG to occur at the same time as other
inline processors, then we have:
p.register('strong','inline',...)
Replacing a processor is as easy as re-registering it. You can also
deregister a processor.
As we all know, dictionary elements are not ordered. The problem of
order would exist even if dictionaries were ordered. This is because
it is possible to register a new processor at any time before parsing
begins and properly ordering in any language's associative array would
be a royal pain. Patrick provides a solution in his code: have each
processor register its relative order via a heap algorithm. When the
heap is sorted at parse-time, the relationships between various
markups resolves to the final process order.
I believe this organizer is more OO than the current Markdown
implementation. Mind you, I come from a couple decades of functional
programming so my understanding of OO is hard-earned. I believe a
proper class avoids having to manipulate its internal structure.
Having to play with self.preprocessor to add
You would add another class to the Markdown suite: "Parser." This
class would have the following methods: register, deregister, sorted,
and parse. The first two should be self-descriptive. Sorted() would
build an array which properly orders the keys for the registered
processors. Parse would receive the markdowned text and convert that
text into HTML.
None Parser.register(key, where, pattern, replacement, constants(e.g. re.M))
None Parser.deregister(key or [keys])
List Parser.sorted()
html_text Parser.parse(markdown_text)
--
Ben Wilson
"Words are the only thing which will last forever" Churchill
|