Re: [podwiki] Re: Unifying output of POD and other markup methods

[Thomas L. <to...@co...>]

Hallo,

On Wed, Jun 02, 2004 at 10:49:47PM -1000, James H. Thompson wrote:
> When thinking about changing the structure of the formatters,
> and if you have any plans to someday support Transclusion -

at the moment there are no thoughts about transclusion. In my case this
is because I just didn't know about this idea :-)

If I think about it, then I realize that implementing transclusion in
PodWiki seems to be *very* easy. Why? Because it uses POD (and this
means: I don't think it will be possible with "foreign" formatters).

Say, I have a document "BlahDoc":

=head2 INTRO

This tells about fish and chips

=head2 RECEIPT

..

=cut


Now I could include part of this document like this:

P<BlahDoc?INTRO>

which includes the content (unrendered!) between the "=head2 INTRO" and
the next "*head" command. This works, because the Pod::Tree parser used
in PodWiki already divides a POD document into sections (internally called
nodes), which makes it very easy to pick out a particular section. Of
course this section must exist otherwise it would not work.

I am unsure how this could to be implemented for external formatters. 

The problem (and that's what David mentioned earlier) is the totally
different way that external Formatters and the POD parser are working.
The POD parser generates a tree of nodes from the document and PodWiki
then walks recursive over the tree while rendering each single node.
An external formatter on the other hand does a big search/replace action
over the whole document. This way is of course somewhat simpler to
implement, but it does not allow to divide the document into sections,
at least it makes it more complicated.

However - my current idea is: What if we completely move to the
tree-parsing technique, also for external formatters? If every renderer
works the same way, it would be much easier to implement new features
for both "worlds". To be frank: ok, we could also do the reverse, we
could re-implement the POD formatter using the search/replace technique.
And to be honest, I already tried to write such a formatter some months
ago (when I started with PodWiki), but I were unsuccessful :-|
The POD format is well suited for regex-parsers. 

So, perhaps it would be a good idea to write a generic tree parser,
which is used by PodWiki for actually rendering stuff. But behind the
scenes, there are specialized parsers which are overwriting some or all
of the methods of the "Super" parser, one for POD, one for Twiki and so
on, PodWiki doesn't know what type of document it is rendering. The
Super parser could provide methods similar to XML tree parsers, in fact,
if someone of you ever worked with XML parsers - they "feel" much like
the POD::Tree parser. This would provide some more possibilities: we
could even render XML directly, or: we could create several output
renderers, one for "online html" (which we are using currently in the
Wiki), or one for "offline xml", e.g. RSS feed, or for site-backup.

Much stuff to think about :-)



regards, Tom

-- 
 Thomas Linden   (http://www.daemon.de/)  tom at co dot daemon dot de
 $_=`perl -v`;s;^.*ll;;s;$^=unpack"u", "'8V]D;')E<```";s;\W;;gs;$/=7*
 ($^=~s;.;;g);%^=map{$_=>1}split//,lc;$_=join$\, (sort keys(%^))[map{
 ord($_)-$/}split//,'1I7E13?@E:7C1A7C=1:35<7C'];s"0(.)" \U$1"g;print;