Moin,
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 preview.
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 extension.
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 usefull. ;-]
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 of.)
So, I'd still like to know how to ask the parser whether it renders for a preview, or for the final save.
Best wishes,
Tels