Tags:
stale_content1Add my vote for this tag create new tag
, view all tags
Canonical Topic Stored Form

To be able to handle some browser idiosyncracies, TWiki topics are preprocessed to bring them to a fixed syntax before being stored as text files.

The transformations that are applied are:

  • 3 spaces are converted to a tab
  • others?

Proposed additions

  • <PRE> formatted lines are preceded by <nop> tag.
    • Rationale
      • <PRE> formatted text will not fire rendering rules for bullets and SectionTitles.
      • We would get the benefit that the rendering algorithm becomes simpler and faster.

Other

  • <B> and <STRONG> are converted to *text*
  • <I> and <EM> are converted to _text_
  • <H1> - <H6> are converted to SectionTitles
  • <HR> are converted to ----
  • and so on ...

-- AndreaSterbini - 28 Aug 2000

Presentation should be independant of the storage layer. Since I haven't had much comment on my plans for initial modularisation and no time, I haven't written much code. I guess this is also somewhat related to the comments in PreCompile.

Dont count of things like txt and txt,v contining exist with my PackageTWikiStore. They make no sense when say using the DBI to provide a TWiki to a cluster of machines.

-- NicholasLee - 28 Aug 2000

My comment comes from the current implementation. In the case of a modular storage layer my proposal for a CanonicalTopicStoredForm boils up to suggesting that we split the rendering module in two functions:

  • renderTopic, who receives the topic text from the storageModule and produces the html page
  • canonicalizeTopic, who formats the entered text in CanonicalStoredForm and then stores the result through the storeModule

Let me see if somebody else is interested in this thread of discussion:

  • should we look for a CanonicalTopicStoredForm?
    • Pro
      • all tools (search, include, toc etc...) can be based on the same simple syntax.
    • Con
      • we cannot easily adapt TWiki to other topic syntaxes
  • or should we make a rendering API?
    • Pro
      • each tool will be defined on the basis of the API
    • Con
      • for each stored syntax we must define the functions in the API
      • we must reimplement the tools
  • or should we base all tools only on the html rendered topic text?
    • Pro
      • Each tool is written once and for all. We catch also html embedded in the topic text.
    • Con
      • We must rewrite the present tools.
      • The rendering process will be more complex.
      • There is a chance that we run into rendering problems due to recursion.

Comments?

-- AndreaSterbini - 29 Aug 2000


I like AndreaSterbini's idea of "beautifying" the text before storing (not considering the storing issues). This could be a necessary feature if a future TWiki is extended with WYSIWYG editing using an HTML editor as discussed in UseHtmlEditorOfChoice. In this case, HTML needs to be stripped to the Wiki syntax so that the text can be edited later on by a user using the current HTML form.

-- PeterThoeny - 29 Aug 2000


I too agree with the idea of using a unified format to store messages. This would ease also their conversion to other format (I'm thinking to coverting the results of a search to pdf or latex or rtf for offline reading, printing or heavy editing). One would need a set of converters.

However, I see a problem: either the text formatting tools of twiki become so elaborate to fulfill all needs, or one is obliged not no use other tools, or the mixed text-html is unavoidable.

Another solution would be to store the messages in a richer format (say XML) and convert them from this format to wikitext before editing and then back after it.

-- FrancoBagnoli - 30 Aug 2000


Proposal for a personalized editing format

My personal preference

<IMHO>
In my opinion, the strongest feature of Wikis (after the possibility to edit pages by Web) is the simple format for writing html text. This lowers the barrier to write html and help users use Wiki for producing content .
The added strength of TWiki is the rich set of tools that help the user in navigating, organizing and managing the content produced.
I am (personally) against having a more complex syntax (anyway, we are free to use the "HTML escape").
</IMHO>

But others certenly prefer otherwise ... and so:

Let the user choose

Given for granted that any editing format will cover only partially the set of tags the user would like to use, and so that any conversion below will be only partial ... I propose that the user can choose the format the topic is shown him for editing:

It's not difficult to write a set of rules to transform most part of the html/xml formatting to WikiSyntax and viceversa. The easiest way to implement this transformations should be by having a common unique storage format and a pair of converters (from/to) any preferred format and the storage format (an example of doing this way is the netlib package tor bitmap conversion).

Pro

  • you leave the user free to edit the topic in the editor he/she likes.
  • there are a lot of converters available for convertion from/to several formats
Con
  • you leave the user free to edit the topic in the editor he/she likes, and so he/she will loose the focus on the content .

-- AndreaSterbini - 31 Aug 2000

I was not clear, I think. I agree that the input syntax should be as much html-free as possible (even more than at present, if possible)

However, we would like to have an uniform syntax in the stored messages, so to ease serching, indexing and converting.

how can it be done:

  1. ) forbid html input and extend the twiki textual representation to include all possibilities
  2. ) convert from text to xml (i.e. html + twiki extensions) in input, store it in xml, convert back to text when editing

This should be completely transparent to users.

-- FrancoBagnoli - 31 Aug 2000

TopicClassification:
FeatureBrainstorming
Edit | Attach | Watch | Print version | History: r7 < r6 < r5 < r4 < r3 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r7 - 2000-08-31 - FrancoBagnoli
 
  • 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.