Tags:
create new tag
, view all tags
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

Drawing is not editable here (insufficient permission or read-only site)


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

Topic attachments
I Attachment History Action Size Date Who Comment
Unknown file formatdraw Render.draw r2 r1 manage 2.6 K 2002-06-23 - 12:23 MartinCleaver  
GIFgif Render.gif r2 r1 manage 5.4 K 2002-06-23 - 12:23 MartinCleaver  
Edit | Attach | Watch | Print version | History: r10 < r9 < r8 < r7 < r6 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r10 - 2004-10-15 - MartinCleaver
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.