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

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

On Thu, May 27, 2004 at 08:46:30AM -0500, David A. Bright wrote:
> What if both forms were changed to, instead of printing (either as-they-go 
> or at the tail end), simply return a string. The strings can be accumulated 
> as the processing continues and then printed at the end of Runner::run.
> 
> This would be a pretty big change, so I thought I'd run it by you first. 
> What do you think?

I thought about it too, but I'm unsure if this makes things better.
I already maintain an (commercial) application written in perl too,
which works this way. There are some other problems coming up, e.g.
if at some point an error occurs. When will it be printed? Will it
be visible (destroyed tables and stuff)? So, what I did in my commercial
application: the whole rendering happens within an eval { } block and
every failure uses die() to tell about it, this will be catched by the
core engine, which in turn then is able to render a proper failure
page.

But in the case of PodWiki this method is unusable, because PodWiki does
not build the page at all (as you know, it just calls "AutoLoad" which
includes the rest). If we would do it this way, error messages will not
occur inside the existing site design but in a "native" build-in design
:-|

So, I'm unsure if we shall do that work (which is really a lot of it).



Tom

PS: btw - I'll be in vacation for one week starting tomorrow, so I will
    not respond til next saturday..

-- 
 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;