[Pmwiki-users] Page preview can now be implemented rather easy

Patrick R. Michaud pmichaud at pobox.com
Tue Jun 17 20:09:47 CDT 2003


I've implemented a test "page preview" feature at
http://www.pmichaud.com/wiki/Development/PreviewEdits just to see
how a preview might be put together.

In looking at it I think that the previews will need to be able to
handle the [[include:]], GroupHeaders/GroupFooters, and other directives 
in order to be useful.  Anyone agree or disagree?  

Pm


On Tue, Jun 17, 2003 at 06:11:54PM -0600, Patrick R. Michaud wrote:
> BTW, just so everyone knows--I'm still planning to add a real "preview"
> feature to PmWiki--I just needed to get the other formatting items out
> of the way first.
> 
> However, this discussion does point out something I mentioned earlier,
> which is that a preview version of a page probably won't look exactly 
> like the displayed page because some customized headers, footers, 
> GroupHeader, included pages, style sheets, etc. may not all be present
> in the edit page output.  Anyone have any suggestions about the way
> this *should* work?
> 
> Should the preview attempt to render $PageHeaderFmt, $PageFooterFmt, etc.,
> and do all of the associated file includes, or should the preview
> just output the page itself?
> 
> Pm
> 
> 
> On Wed, Jun 18, 2003 at 10:07:08AM +1200, John Rankin wrote:
> > Bernhard, that is very useful.
> > 
> > Using your idea, I created a short script that does the same thing for a standard PmWiki install -- an adminitrator just includes preview.php (available on request). It introduces a preview action and a HandlePreview function.
> > 
> > Where I have got stuck is dealing with [[...]] directives, such as [[include: or [[nogroupheader]] in the preview.
> > 
> > Both the PrintText function and $PageEditFmt by default use $Text, so if I change $Text to deal with [[...]] stuff, it will also change the form contents, which I clearly don't want. I assume there is a way I can tell the array that defines the preview screen display to pass a $PreText parameter to PrintText, as you have done, and use $Text in the form, but I haven't tried it yet.
> > 
> > Incidentally, based on seeing how the HandlePost function works, you may need to write:
> >    $newtext=str_replace("\r","",stripslashes($HTTP_POST_VARS["text"]));
> > This might be why your InlineReplacements aren't working.
> > 
> > I also have a minor, but annoying, problem of leading and trailing 'return' characters being stripped off. So my GroupFooter which starts with ---- keeps getting turned into 2 em dashes (SmartQuotes finds inline --, because the ---- is no longer at the start of a line and doesn't get turned into a <hr />).
> > -- 
> > John Rankin
> > 
> > On Monday, 16 June 2003 7:28 AM, Bernhard.Weichel at t-online.de wrote:
> > 
> > Hello Patrick,
> > 
> > due to the new features in 0.5.x (in particular PrintText) it is now
> > possible to implement the highly desired page preview feature. Here is the
> > code, I am using.
> > 
> >  else if ($myaction=="edit" | $myaction=="preview")
> >    {
> >     global $HTTP_POST_VARS, $Text;
> >     $newtext=$HTTP_POST_VARS["text"];     // don't know how the text should be processed
> >                                           // it seems that fixing inlines must be done here
> >     if ($newtext=="") {$newtext=$Text;}   // if preview was called directly, not via edit
> > 
> >     if ($myaction=="preview") {PrintText($pagename, $newtext);}
> > 
> > ...
> > 
> > 
> > 
> > 
> 
> _______________________________________________
> Pmwiki-users mailing list
> Pmwiki-users at pmichaud.com
> http://pmichaud.com/mailman/listinfo/pmwiki-users_pmichaud.com
> 




More information about the pmwiki-users mailing list