[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