On Thursday 13 April 2006 15:01, Phil Boswell wrote:
Brion Vibber wrote:
> Tels wrote:
>> I would like to generate different output depending on whether my
>> extension code is triggered for a preview, or for a save.
> Please don't. Among other things, this defeats the purpose of a
I knew you would say this :(
With my preview I have a few problems that would be addressed by this:
* fontsize change. The user can specify a global percentage of making the
font bigger. Unfortunately, this affects #bodyContent (or however it is
actually named, I forgot the name). Works fine for the saved article, but
_also_ includes the preview/edit area (that arguable a bug, but fixing
that needs introducing another div into the output in the mediawiki
source code). So when you preview, suddenly all buttons etc, texts are
also bigger. This makes editing _very_ hard.
Of course, not seeing the real fontsize can be a bit problematic, too, but
then, you can't know in what final base fontsize the entire article will
be displayed, as every viewer is free to use CTRL+<+> and CTRL+<-> to
change it at will. So I'd rather have a workable preview mode, and see
the outcome in fontsize after saving.
* UI change. My extension makes certain user elements disappear in the
saved article for more viewing space (yeah, I can hear you already say
"dont do that". However, it is nec. and usefull. When you present text,
you dont want the menu. You dont print it, either, right? :-). However,
during preview one might actually want the menu box, and the toolbox
visible, only to have them disappear at save time.
It is of course possible to disable both the fontsize change as well as
the disappearing UI elements, as well as the preview-differes from save.
So, for users who *want* that functionality, it must be implemented in the
I can certainly see where this might actually be a
good thing to do.
For example in the case of Aevar's <ref> extension it has been
suggested that in cases where a section is being edited which contains
<ref> tags but no <references/> tag, the extension might be able to
produce a preview of what would appear without the user having to
introduce a temporary <references/> (which would run the risk of their
forgetting to remove it
I am not sure I understand it, I just know that the feature can be
Another idea is that for extension producing graphics or other inline
elements, a "preview" is (*Gasp! Shock! Horror!* :-) a preview, e.g. it
is maybe rendered with a reduced quality, but faster. Only when you save
the real final-quality image is produced.
Another problem is that when a preview is produced, my graph extension
(and any other extension producing files) leaks a file: Hash the contents
to render to filename, produce preview, user then edits the contents,
saves, a new file is generated. The file from the preview is, unlike
files from former editions of an article, no longer accessable.
With a dedicated preview action the file could be stored into a different
temp folder, which could be cleaned out at any time without any risk of
loosing files that are still referenced in real articles.
(In fact, this point is the strongest point for determining =preview,
because it would stop almost all leaks of files from my extension. The
only ones left are from deleting articles and are much harder to get rid
So, I'd still like to know how to ask the parser whether it renders for a
preview, or for the final save.
Signed on Thu Apr 13 19:14:38 2006 with key 0x93B84C15.
Visit my photo gallery at http://bloodgate.com/photos/
PGP key on http://bloodgate.com/tels.asc
or per email.
"We're looking at a future where only the very largest companies will be
able to implement software, and it will technically be illegal for other
people to do so." -- Bruce Perens, 2004-01-23