I propose that TWiki's primary capability is as a rendering engine.
It renders ascii formatted text as
HTML.
I think that there would be great value in capturing in a module the Rendering Engine and its related chain of Plugins.
This would mean that
RenderDotPm would contain the following currently stored in
TWikiDotPm:
- sub getRenderedVersion
- sub handleIncludeUrl
- sub handleIncludeFile
- sub handleMetaSearch
- sub handleSearchWeb
- sub handleTime
- sub showError
- sub handleToc
- sub handleWebAndTopicList
- and so on ...
I also propose that we consider TWiki Plugins to really be the Rendering engines plugins. After all, what if we want to plug-in to the Parse chain or to the Access control chain or to the workflow chain?
--
MartinCleaver - 23 Jun 2002
Yes, I think that seperating the rendering engine out would make a lot of sense. But i think we should think about other Plugins too. the
SoapClientPlugin, and your
WebServicesPlugin could / should be data access plugins - I've only implemented mine as a rendering plugin as its the only game in town.
I think rendering is one obvious part of the TWiki, another could be a flexible backend, and the last would be user configurable integration using combinations of
TWikiTopics
--
SvenDowideit - 20 Sep 2003
In Owiki:Openwiki.HighLevelCodeDesign terms, the separation of rendering corresponds to tiers 3 & 4:
tier |
responsibility |
4 |
Formatting/Parsing |
3 |
Integration/Expansion |
Having the data access you propose is key, it would be a real enabler of progress.
--
MartinCleaver - 20 Sep 2003
I'd really like to separate out the rendering engine and make it more modular and pluggable. Also, I think
InterwikiPlugin should either be brought into the rendering engine (to enable links to
InterWiki sites that have alternative link text), or the rendering engine should enable plugin-generated links to be used within
EasierExternalLinking type links.
One specific issue for
ProposedUTF8SupportForI18N is to enable separate character set encoding and decoding modules (though mostly these will just use
CPAN or core Perl modules), and for
I18N generally to enable easy access by plugins to
I18N-safe regexes defined by the
setupRegexes
routine at present in
CVS:lib/TWiki.pm.
I've created an
InterWiki link for O'Wiki - not sure of the exact spelling required since there are several at
http://owiki.org/, so let me know if this should be changed.
--
RichardDonkin - 22 Sep 2003
A separated render engine would be very useful.
I always wanted a to pipe the output of old
CGIs into TWiki.
The resultion "virtual" TWiki pages would blend seamlessly into the regular TWiki pages,
giving standard look & feel, navigation and linking.
--
PeterKlausner - 22 Sep 2003
What does "compatibilityMode" try to do in
sub makeAnchorName
? This looks like a bug to me:
sub makeAnchorHeading
creates 2 anchor links for a H1 header, when two !! are added (to prevent the header from being listed in the TOC):
---+ ButtonClip
result:
<a name="ButtonClip"> </a> ButtonClip </h1>
---+!! ButtonClip
result:
<h1><a name="ButtonClip"> </a><a name="_ButtonClip"> </a> ButtonClip </h1>
I wouldn't find it illogical when a header with !! does not have an anchor link at all.
--
ArthurClemens - 18 May 2004
This is done by design so that old links to anchors do not break. Double anchors are only produced if the old and new format differ.
--
PeterThoeny - 20 May 2004
But the strange thing remains that the double anchor is only created when a !! is added to the
---+
tag.
--
ArthurClemens - 20 May 2004