I have take the liberty to extend the twiki table syntax. In doing so perhaps I have discovered a potential extension point in twiki itself.

The Proposal

Currently rows in twiki tables must be on lines by themselves. For example, the following table is legal:

| a | b | c |

Where the following are not legal

| line1
  line2 | b | c |

or

| line 1
  line 2 | line 2 col 2 
           line 3 col 2 | line 3 col 3 |

The proposal is to modify the twiki table syntax to comprehend the more flexible table entry syntax.

Rationale

The big advantage of the specialized twiki syntax over raw HTML is that it preserves a sense of formatting in an unformatted document. For example a table:

| a | b | c |
| d | e | f |
| g | h | i |

a	b	c
d	e	f
g	h	i

Looks visually the same in html as it does in twiki syntax. This is a huge advantage for editing data.

Unfortunately, the twiki syntax for tables breaks down when the contents of any given cell become longer then a line. Visually, we could still maintain the illusion of columns:

| This is some interesting
  Information that exists
  In column 1.             | In column two we are going
                             to talk about something 
                             different                   | Column 3 |
| This is the second row
  And first cell           | It might have different info| Column 3 |

As you can see, the visual separation of rows and columns is still noticeable from the edit window. In "normal" twiki, this table would look like:

| This is some interesting Information that exists In column 1.
             | In column two we are going to talk about something
 different                   | Column 3 |
| This is the second rowAnd first cell           | It might have
 different info| Column 3 |

I inserted Carraige Returns at the appropriate places to simulate what it looks like when wrapping lines in the editor. Milage will vary depending on the width of the editor

As you can see, this quickly degrades into a guessing game about what symbol matches to what element in the table.

Implementation

The implementation turned out to be surprisingly easy.

# Table of format: | cell | cell |
            if( $_ =~ /^(\s*)\|.*\|$/ ) {
                $_ = "$incompleteRow$_";
                s/^(\s*)\|(\s*)(.*)/&emitTR($1,$3,$insideTABLE)/eo;
                $insideTABLE = 1;
            } elsif( $_ =~ /^\s*\|/ ) {
                $incompleteRow .= "$_";
                $_ = '';
            } elsif ( $incompleteRow and /\|$/ ) { # table row ends
                $_ = "$incompleteRow$_";
                s/^(\s*)\|(\s*)(.*)/&emitTR($1,$3,$insideTABLE)/eo;
                $insideTABLE = 1;
                undef $incompleteRow;
            } elsif ( $incompleteRow ) {
                $incompleteRow .= "$_";
                $_ = '';
            } elsif( $insideTABLE ) {
                $result .= "</TABLE>\n";
                $insideTABLE = 0;
            }

Note there are some variables that must be declared. This code is placed in wiki.pm, at about line 1014.

Problem

The Problem with this proposal is that it replaces the original formatting of tables by modifying the wiki.pm module. I don't think this is sucha good idea. First of all, it makes upgrading significantly more difficult.

As it turns out twiki as an extension mechanism built in to handle this type of scenario. By implementing the method:

extendGetRenderedVersionOutsidePRE( $_, $theWeb );

in wikicfg.pm, you can add new formatting tags. The problem is it doesn't allow you to replace default wiki behavior.

I think the appropriate thing to do is to modify this extension model to allow replacement of certain operations. Perhaps we can define a set of operation codes. In side the wiki.pm module, we check to see if any of the operation codes have been performed before processing the line for a given operation. The extendGetRenderedVersionOutsidePRE will return what operation codes it performed on a given line, allowing the core twiki code to skip over any lines that have previously been processed.

Comments?

Suggestions?

-- MichaelKirby - 17 Jan 2001

I prefer not to take this syntax into the TWiki core to keep the rule simple and to avoid unwanted side effects.

Regarding overloading table rules, you can do that but we first need to provide two more hooks in sub getRenderedVersion:

• Existing hooks:
  • extendGetRenderedVersionOutsidePRE (renamed to outsidePREHandler with TWikiPluginAPI) to handle lines outside <PRE>
  • extendGetRenderedVersionInsidePRE (renamed to insidePREHandler with TWikiPluginAPI) to handle lines inside <PRE>
• New hooks:
  • getRenderedVersionInit to handle customized initialization of getRenderedVersion
  • getRenderedVersionCleanup to handle customized cleanup of getRenderedVersion

With those in place you can handle your table rules:

• Initialize variables in getRenderedVersionInit hook
• Do table rule in outsidePREHandler hook
• Finish table in insidePREHandler and getRenderedVersionCleanup hook

Your table rules will overload the TWiki internal table rule because the outsidePREHandler hook is called before any other rendering rule takes place. TWiki does nothing with the | characters since they have been already converted into the HTML table format in the outsidePREHandler hook.

-- PeterThoeny - 27 Jan 2001

---

I've thought a lot about tables in Twiki. At this point, it's just about as easy for me to use HTML table tags than to use the | stuff. But consider this wild idea...

I'm thinking of almost a model/view sort of thing. First have an area where you just put the raw data that goes into your table. Then have an area where you say 'draw that data here'. This drawing of the data is done totally dynamically by the Twiki CGI script. Advantages include:

• More smart formatting options. The Twiki script can peruse all the data first, then draw it correctly. This would let it do things like cleanly draw blank cells, which is something that looks cheezy in HTML tables; e.g.

Column Heading 1	Column Heading 2
I am a	nice pretty Row
An anal user put the needed   in the next column
An somewhat lazy user put in 2 columns but left the second one blank
An extremely lazy user didn't even bother to put the second column

• Less chance for Twiki to get lost. If you shove something big into a table cell, the Twiki formating rules get consufed and you have to go back and forth to get what you want. Because the data is separate from the formatting this problem goes away.

• New abilities, normally impossible such as column sorting. Wouldn't this be great? Having an auto-generated sortable table!?

• The ability to sum-up data automatically (the original thread of this message).

• Graphing abilities - you can take the same input data and render it as a table and/or graph it. If done flexibly enough, this could let you do things like have Twiki automatically draw graphs of its usage vs. time, pie charts of contribution by user, etc.

I don't know about you but this is kind of exciting to me!

-- MattWalsh - 22 Jan 2001

I prefer to keep the TWiki core syntax simple. This is a perfect example for a TWikiPlugin. Hmm, I need to reserve time to put the TWikiPluginAPI into the TWiki core.

For now I eased the table syntax a little bit: Trailing white space after the last | character is now accepeted, previously it would break the table. Commited to TWikiAlphaRelease.

-- PeterThoeny - 27 Jan 2001

There is a way to split up a long row into several lines. Read TableEditingProblems.

-- PeterThoeny - 10 Feb 2001