I think that this could be achieved by having a MetaData field for the topic to specify the type of page (e.g. TWikiML, HTML, MS Word, MS Powerpoint). On 'edit' the appropriate editor could then be invoked.

Having an association TWikiML/edit=iejs would solve the IejsIsNotASkin problem as well.

Just think...

-- MartinCleaver - 23 May 2003

MetaData is one way to adapt this. But, this type of functionality is typically handled by the file extension. Right now, TWiki only handles .txt extensions. Some other wikis can handle a few other extensions. Just thinking outloud ...

-- TomKagan - 23 May 2003

Hmm. Very good observation. You got me thinking again Tom.

Maybe the wiki page, in the .txt file, should just be the default content to be shown for any given wiki word, but for all other intents and purposes it can be treated like an attachment, with the type .tml (TWikiMarkupLanguage / TML). The MetaData therefore historically points to this .tml file.

This is linked to another VERY interesting factor - Crawford/Anton's discussions about MetaDataStinks, and that MetaData should be separate to the content of the page.

If we were to move the .tml content out to an attachment, and keep only the meta data in the .txt file we would not implement natural separation of Content and MetaData but also provide for page type differences in a way (i.e. by file extension) that is compatible with the rest of the world.

Certainly seems preferable to keeping TML content in a TXT file. After all, surely TXT implies don't render?

-- MartinCleaver - 24 May 2003

Indeed.

An Object Oriented model hadles the type of the object automatically ( or automagically? ) and so a TopicObj would have a doRender() method that did the appropraite thing with appropriate over-rides supplied by plug-ins.

Of course this would all have to be configured by the administrator, allowing differnet types of topic body. The obvious one is HTML for which the doRender() is of course a null opertion.

What's more interesting is that this opens up some dramatic vistas for applications. The topic does not need to be a file or an entry in the database. It can be generated dynamically on access, and the information provider can be anything you want, so long as it supplied the information in a format suitable for the rendering mechanism.

This instantly simplifies the interface to WebServices, to LDAP databases for contact lists and calendars, and many other things.

Watch this space for my upcoming Object Oriented TWiki work, now being whiteboarded in my office.

-- AntonAylward - 26 May 2003

TWiki:: RenderDotPm ::render can then hence be specialised designated by the META item, according to the PageType orginating app and version:

Convert Native to HTML

• TWiki::Render::HTML::renderAsHTML (a null op)
• TWiki::Render::TWiki::TML::renderAsHTML (today's impl)
• TWiki::Render::TWiki::TML::Athens::renderAsHTML (legacy)
• TWiki::Render::TWiki::TML::Dakar::renderAsHTML
• TWiki::Render::TWiki::TXML::Edinburgh::renderAsHTML (as per Adam's idea)
• TWiki::Render::OfficeApplication::MS::PowerPoint::renderAsHTML (as per Anton's point)
• TWiki::Render::OfficeApplication::MS::Word::renderAsHTML
• TWiki::Render::OfficeApplication::MS::Access::renderAsHTML
• TWiki::Render::OfficeApplication::OpenOffice::Presentation::renderAsHTML
• TWiki::Render::OfficeApplication::OpenOffice::Word::renderAsHTML
• TWiki::Render::StructuredText::renderAsHTML

-- MartinCleaver - 15 May 2004

A far-fetched idea: How about have TWiki store all pages and content as simply XML confining to some schema either created by TWiki or some documentation standard. Then the TWiki scripts can have modules for editing and displaying this XML as different formats (ex: "TWikiML", "HTML", "PDF", "MS Word", etc).

• Y, TML is a non-XML TWikiMarkupLanguage -- MRJC

For an example: the user could click on the "Edit" link, then TWiki would fetch the XML for that page, parse it into TWikiML, and present this modified content in a text area box for user editing. Upon save, TWiki converts this TWikiML back into the native XML.

The big benefit of this would be an abstract storage layer that allow for the same content to be presented to the user in a wide variety of ways, easily configurable by the site administrator through the modules. The familiar TWikiML could be one module, but other wiki ML's could co-exist as alternative options. Administrators who don't like the traditional TWiki format can switch to another, or provide users with the option of what they want to edit in.

• Good idea - versions added above. - MRJC

In this way TWiki would become a MetaWiki, providing a common framework for admins to easily roll-their-own wiki as they want.

• Not far fetched at all. That is what I was getting at. Certainly that can be (and just has been) incorporated into the schema above, but I also believe that it is important to embrace existing non-XML document standards, and have those render according to the output format channel. My naming above assumes TXML (an XML version) coming in as a feature of Edinburgh, but I think we will have more likely adopted this is optimistic - MRJC - 15 May 2004

-- AdamTheo - 15 May 2004

If ... if ... if ...

If we move to an object abstraction for the topic a number of things are possible.

• Absolutely - at WikiSym2005 we spoke extensively about the need for a TopicObjectModel.

Let me talk, just for the moment, in terms of a YAML representation, since that's easier to read than XML or to draw than a object-relational-parts-and-whole diagram.

The result can be stored any how. One file with some internal structure, as YAML, as XML, as a number of fields and tables in a relational database ... The Store.pm could recognise different types of storage for different webs ... but that's another issue.

Here's the structure:

--- #YAML:1.0

Topic:
   Metadata:  # maps to hash
       ID:
         Author: AntonAylward
         Revno:  1.2
         Date: 1012345
         Version: 1.0
       Moved:
   Access:
       ALLOWCHANGE: 
       DENYCHANGE: Main.TWikiGuest
   Attach:  # Array of attachment info, each one a hash
        ......
   Body:    # Ordered array of parts, each part a hash
      - Lang: en  # first past is in english ...
        Edit: yes       # ... is editable
        Type: TWikiML
        Body: |
             Body text goes here
      - Lang: en
        Edit: no         # this is fixed text
        Type: HTMLfile   # pre-formated HTML
        Body: 'StandardDisclaimer.html'
... 

See also ImplicitNamedSections FineGrainedAddressing PackageTWikiStore and in particular PurpleNumbers

Which opens up more possibilities.

• Knowing its HTML means it can be cached, doens't have to be rendered ... and other matters that have been discussed.
• Knowing the language .... the type ... perhaps syntax directed editors?

-- AntonAylward - 27 Oct 2004

I just realised that WysiwygPlugin tries its utmost to convert pasted HTML into TML and in some cases can only fail.

If we had PageTypes a user could elect a page to be HTML and thus we would not care for conversion. In a HTML page when I paste a HTML table and WysiwygPlugin would not need to attempt conversion on it.

Err... why do we need TML at all when the Wiki can just contain HTML pages?

-- MartinCleaver - 30 Oct 2005

http://koala.ilog.fr/twikiirc/bin/irclogger_log/twiki?date=2006-07-22,Sat&sel=554#l550

MartinCleaver:  Plugins.BeautifierPlugin
MartinCleaver: These code types:
MartinCleaver: %CODE{"cpp"}%    void foo() {      print("Do stuff.\n");    } %ENDCODE%
MartinCleaver: really TWiki has implicit PageType = TML, equivalent of %CODE{TML1}%
MartinCleaver: this implicates pages to be interpreted as TML pages
MartinCleaver: verbatim should be used whereever PageType = unknown
MartinCleaver: Hmm. That  format="1.1" in the %META:TOPICINFO{
MartinCleaver: could easily be made to incorporate !PageType
Drusilla: Well, we ought to be bumping that number soon anyway
MartinCleaver: i.e. format= "1.1; TML" or format = "1.2; TML" or format = "verbatim"
MartinCleaver: or format = "1.0 MediaWiki"
Drusilla: Ah, very nice idea
MartinCleaver: or format = "1.0 textile"
MartinCleaver: or format = "1.0; css"

-- MartinCleaver - 22 Jul 2006

I note that JotSpot now has the concept of page types as does Sharepoint2007. Rock-on TWiki.

-- MartinCleaver - 01 Aug 2006

This is possible with a preferences setting, and is documented in WysiwygPlugin (albeit not so clear)

• Set COMPOSER =

Above line disables the WysiwygPlugin. Try to edit this topic with the WYSIWYG editor.

It would be helpful to have this better integrated though. If the WYSIWYG editor is disabled there is no need to show the WYSIWYG edit link.

-- PeterThoeny - 01 Aug 2006

Does the composer just offer a different editor for TML content or does it actually provide page types, i.e. driving the page from an attachment or a whiteboard that contains different content type e.g. mediawiki format?

-- MartinCleaver - 01 Aug 2006

I think this is pretty much WysiwygPlugin specific.

For different edit syntax see EditSyntaxPlugin.

-- PeterThoeny - 01 Aug 2006