Hi all,
I hope that this isn't too out of left field, especially coming from a
relative unknown. I do however think that this is a conceptual problem in
the Parser class which ought to receive some attention eventually.
You see, it seems to me that the Parser is in fact more Renderer than it is
parser, and most of the options in ParserOptions are in fact Rendering
options.
I noticed this while working on a tag extension for events. My goal was to
parse some wikitext to obtain an array of PHP objects of a class Event
which cooresponds to a an "event" tag I've defined. Well, I can sort of
pull this off by creating a special parser, and adding parser hook which
builds the objects for each array and sticks them into a global. Of course
to do this I need to initialize the parser with a ParserOptions object, and
of course the parser goes on to render HTML which I don't actually want,
since the goal is just to get the intermediate stage.
It occurs to me that separating the Parse stage from the Render stage could
have some other useful effects, like making it easier to add different
renderers, and making it a bit easier to start on the Parser
rationalizations that people have been talking about.
Of course any such separation will mean having to specify at least some of
the parser and renderer behaviour, but maybe not all. At any rate it
should make it easier to do so.
So my question is this: does separating the two functions seem like a
worthwhile task to anybody else here?
Thanks for you time,
-mark
--
--
=================================================================
-- mark at geekhive dot net --