podwiki-devel

[podwiki] Unifying output of POD and other markup methods

[David A. B. <Br...@ac...>]

Tom,

I've been thinking for a while about the behavior of the different formatters. 
What got me started on this is the fact that we have two different pieces of 
code to produce links, one for POD and one for the other formatters. They 
can't be combined due to the behavior of the non-POD formatters. POD first 
parses everything into a tree and then runs through the tree, "print"ing every 
node in the tree. The other formatters, however, do a "search and replace" 
style of formatting within the input text. After everything is formatted, then 
they print (some doing minimal post-processing to form paragraphs).

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?

-- 
David A. Bright
Br...@ac...
dab...@us...

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;

[podwiki] Page rename/move

[David A. B. <Br...@ac...>]

I've been giving page rename/move some thought. I'm not sure how to do it 
yet. A few issues:


- Different formatters make this a potentially a little more difficult, as the 
linking form is different for each one. We probably need an interface in each 
formatter to handle the conversion.

- Direct HTML links (i.e., directly coding a <a href=...>) are probably not 
worth trying to handle.

- It may be desirable to leave a "redirect" page with the old name.

- How do we know which pages have links to the page to be renamed?

One possibility is to keep track of the links that each page has. This would 
be updated on each save of the page and then that could be consulted. I think 
this would require the formatters to return information about links as they 
render the page. The danger here is that this record of links could get out of 
sync; there might need to be a way to force it to be reconstructed. If that is 
the case, should we even bother with it at all? Another question is where 
would this information be kept? Keeping it in a central location might lead to 
locking problems. Keeping it one a page by page basis would alleviate that, 
but, again, where to store it (e.g., a .PageName.links file?).

Another possibility is that we search at the time of rename. This could be 
time consuming, but would eliminate the problem of keeping link lists in sync. 
Since rename is a relatively infrequent operation (I'm making an assumption 
here!), maybe the time penalty is not too serious. Again, this probably 
requires a "rename" interface in the formatters.

With either of these approaches, there is the question of what to do when a 
page that is currently locked has references that need to be renamed.

Just a start on some thoughts here. Let me know if you have any comments or 
other ideas. I'm sure there are things I haven't thought of yet.

Thanks.

-- 
David A. Bright
Br...@ac...
dab...@us...

Re: [podwiki] Page rename/move

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

Hello David,

at first: please do not send such mails To: me and Cc: to the list,
because SF's mailman seems to ignore Cc:'ed mails to the list and
therefore does not set a reply-to field. That causes me to rewrite the
mailheader of my ansers manually.

On Thu, May 27, 2004 at 10:07:30AM -0500, David A. Bright wrote:
> - Different formatters make this a potentially a little more difficult, as 
> the linking form is different for each one. We probably need an interface 
> in each formatter to handle the conversion.

What if we centralize the pod_link() function (which is afaik on the
todo list anyway) and let it register each link?, e.g. you call it this
way: pod_link($from, $to), where $from is the page which contains the
link and $to is the destination. We could use a Storable for this, the
same way as attributes or users are saved. The current implementaition
seems to be lock-save and stable (at least I had no attribute lost on
daemon.de since I updated it to 0.8.0). What do you think?
 


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;

Re: [podwiki] Page rename/move

[David A. B. <Br...@ac...>]

On Thu, 27 May 2004, Thomas Linden wrote:

> at first: please do not send such mails To: me and Cc: to the list,
> because SF's mailman seems to ignore Cc:'ed mails to the list and
> therefore does not set a reply-to field. That causes me to rewrite the
> mailheader of my ansers manually.

Sorry about that. That is what happens when I reply to your emails (such as 
this one). I'll just try to remember to whack the Cc:.

> On Thu, May 27, 2004 at 10:07:30AM -0500, David A. Bright wrote:
>> - Different formatters make this a potentially a little more difficult, as
>> the linking form is different for each one. We probably need an interface
>> in each formatter to handle the conversion.
>
> What if we centralize the pod_link() function (which is afaik on the
> todo list anyway) and let it register each link?, e.g. you call it this
> way: pod_link($from, $to), where $from is the page which contains the
> link and $to is the destination. We could use a Storable for this, the
> same way as attributes or users are saved. The current implementaition
> seems to be lock-save and stable (at least I had no attribute lost on
> daemon.de since I updated it to 0.8.0). What do you think?

Interesting idea; this might minimize the impact of making the change and that 
is always attractive. Of course, we have to figure out how to utilize pod_link 
for links in the POD formatter (or vice-versa), which is kind of what my other 
message on unification of formatters (not really markup) was about.

Anyway, assuming that is the case, the only problem I see with that is that it 
would happen on each read of a page, which would mean there would be a lot of 
(redundant) updates to the Storable. Unless, of course, we can somehow 
restrict that mode to only the rendering of the page immediately after the 
save.

Maybe I'll find some time to play with it a bit while you're away. There's a 
scary thought!

-- 
David A. Bright
Br...@ac...
dab...@us...

Re: [podwiki] Page rename/move

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

On Thu, May 27, 2004 at 11:59:40AM -0500, David A. Bright wrote:
> Anyway, assuming that is the case, the only problem I see with that is that 
> it would happen on each read of a page, which would mean there would be a 
> lot of (redundant) updates to the Storable. Unless, of course, we can 
> somehow restrict that mode to only the rendering of the page immediately 
> after the save.

the function could have a simple flag indicating that it should now
update the storable file. I think this must be a global flag or
something, its default value is 0 and the save() function sets it to 1
after the rcs check-in, because after that it just calls the render
function for the new page so that a user gets the new page displayed
after saving it. The only problem left is to generalize pod_link so that
each formatter and the pod walker's are using it.


Well - have fun playing around with this :-)



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;