Complex Table Plugin Idea

Goal

Imagine a complex table like the one below (colours and borders are just to show how the table is built) ...

  This is my verbatim stuff.

... written fully in TWiki markup.

How it could be done

( *Left*                      | *Center*                 | *Right Column* )
-
( This is my Table.           | For example, it contains | ( this is cool | because )        )
( Containing complex Text.    |   * This                 | -                                 )
(                             |   * nice                 | ( there is | a nested table )     )
( In several paragraphs       |   * list                 |                                   )
-
( Then I can insert <verb atim>  |<verb atim>                    |  )
( stuff like this:              |  This is my verbatim stuff.  |  )
(                               |< /verb atim>                   |  )

• Every field of the table is formatted fully recursivly. So everything that's possible in topic text is also possible in a table field.
• The ( and ) brackets are used to avoid ambiguity with nested tables. There could be used something else, like [ ] or { } or / \ or < > or |- -| or ... If there wheren't nested tables, i think it wouldn't be needed (but something to distinguish from regular tables).
• For colours and borders something similar to the TablePlugin could be used (%TABLE{}%)
• The - sign is to break to the next row.
• Of course the | sings don't have to be adjusted, it's just for better readability.

Start and End Tag

There could also be a start and end tag to allow a line like

(This should become a table)

-
(Now it could be a table)
-

Nested Tables

No, they are not necessary. Possibly they make things to complex. But I thought: if you do complex tables right, its just a matter of consequence.

So if they don't make things to hard... why not?

So far...

Why at all?

• Some users (including myself) dont understand why tabes in TWiki are this simple and why it is impossible to have for instance a bulled list in a table. (Now you can tell them: "So you want it more complex? Here you have it more complex!" ) Actually I can't imagine a simpler solution.
• It would indeed be one of the most complex TWiki markup definitions, but using HTML is not a solution for the "regular" TWiki user.
• The syntax would work well together with existing TWiki Markup and would not affect it. So it does not make the markup for simple tables more complex.

Editing Pitfalls

Larger tables would need good text editors to cope with. (And who of all this msword-infected windows users even knows a good text editor?) And even if you have one, it would be hard to write some additional lines in a field or to insert a column...

Why not a more HTML-like Markup?

An alternative markup would be something like

%TABLE%
   * First field
   * Also in TWiki markup
%NEXTFIELD%
   * More text in the second field
%NEXTROW%
   * Here it goes to the next row
%NEXTFIELD%
Is this really easier to read and write?
%ENDTABLE%

This could easily be managed by %SEARCH{}%, because fields in a row are one below the other, and not side by side. For people it is harder to read.

I like my markup much more, because of it's pseudo-WYSIWIG nature. Fields are arranged like they will be in the rendered version.

So possibly you need a good text editor, possibly it will be hard work to rearrange large tables... but, you will always know what you have to do!

Not an easy job for %SEARCH{}%

Table generation with %SEARCH{}% or other text generators would be a real challenge. It's not possible just to render one line per row. The row actually must have as many lines as the field with the highest number of lines inside has. All other fields must be filled up with empty lines.

Example, a list of topics with the formatted content in a table:

  %SEARCH{topic="ComplexTablePluginIdea" scope="topic" complextable="( *$topic*$p$p$twikiusername, $date | $text )"}%

would produce a table like

( ComplexTablePluginIdea | %TOC% )
( Main.StefanSteinegger, 24 Feb 2005 - 21:43 | )
( | ---+ Complex Tables Syntax Plugin Idea )
( | )
( | ---++ Goal )
( | )
( | Imagine a complex table like this one below (colours and borders are just to show how the table is built) ... )
...

Thats would be rendered to

May be this would be to hard to do.

Discussion

Tell me what you think!

Why not simply use the already available RecursiveRenderPlugin together with the established markup for tables instead introducing additional complexity?

-- FranzJosefSilli - 25 Feb 2005

I didn't know this. Looks like it solved much of the complex rendering stuff in a simple way.

But... lets take a table with about fifty rows, every of them conatins a bullet list. That is pretty common, it could be a piece of a protocol or something like that.

Do you have to build the whole content outside the table to include it as a macro call afterwards? This would be hard to maintain and some users wouldn't accept it. Something like the CommentPlugin is also hard or impossible to adapt, because your row is splitted into two (or even more) parts.

But you're possibly right that it wouldn't be worth the complexity.

-- StefanSteinegger - 25 Feb 2005

You can do all what you describe above with a little extra work when you are using MultiEditPlugin, putting the edit attribute to 0. Admittedly, you have to put the tag around the table cells containing bullet lists or other tables. That could be easily avoided by writing a plugin that uses, e.g., your syntax and then works just like TablePlugin, but formats every table cell as a MultiEditPlugin section.

-- ThomasWeigert - 29 Nov 2006

In our internal TWiki we struggled with the same need. Our solution was to create an %EMBED{}% plugin which did the Recursive rendering while allowing the table parsing to continue. Example:

| One | Two | Three |
| Fred| Sue | %EMBED{---++ Header here
   * Bullet here
      1 numbered item
   * Another bullet
}% |

This has worked quite well. Another alternative is to use MediaWikiTablePlugin which MichaelDaum implemented to provide for richer table description.

-- CraigMeyer - 30 Nov 2006

Here is your example done using EMBED

| *One* | *Two* | *Three* |
| %EMBED{This is my Table. Containing complex Text.

In several paragraphs }% | %EMBED{For Example, It contains
   * This
   * nice
   * list.
}% | %EMBED{
| This is cool | because |
| there is | a nested table |
}% |
| Then I can insert &lt;verbatim&gt; stuff like this: | %EMBED{<verbatim>
  This is my verbatim stuff.
</verbatim> }% | &lt;empty cell&gt; |

(Note: The sort links don't work!)

-- CraigMeyer - 30 Nov 2006

So interestingly, we have 3 plugins doing exactly the same thing.

-- ThomasWeigert - 30 Nov 2006

For the record, EMBED is only a function with 7 lines of Perl I tucked it into another Plugin.

-- CraigMeyer - 30 Nov 2006

Wouldn't it make sense to "tuck" the EMBED functionality into the standard TablePlugin as that already has the additional feature EDITCELL embedded? -- Hm, there is a name clash with the existing EmbedPlugin, maybe you could use (RENDER)CELL instead of EMBED. -- What about the rendering performance?

Maybe the problem with <verbatim> in cells is because the opening and closing tag must stand on their own lines, IIRC.

Seven more lines of Perl more or less won't make TWiki die.

-- FranzJosefSilli - 30 Nov 2006

Yes, I agree. Adding it into the TablePlugin, and properly naming it is a good idea.

I am working on the "verbatim" problem, it is a result of recursively calling the getRenderedVersion() function.

As for comparison to the RecursiveRenderPlugin. As I understand it, a registered MACRO is lighter than something requiring a hook into the rendering process.

The mediawiki syntax is much richer than TML, and so should be used when someone needs that level of control (or is already comfortable with that syntax). This could also be implemented within a single new MACRO, WMTABLE ??? and so avoiding another render hook call. But, that is not my call.

I do enjoy the simplicity (implementation and use) of MACRO's within TWiki and the fact that they only add a cost when they are used.

-- CraigMeyer - 01 Dec 2006

Craig, could you please attach these "7 lines of Perl" to this topic?

-- ThomasWeigert - 11 Dec 2006

Sure

Note: <verbatim> will NOT be handled properly (ie; Not at all, it gets eaten)

Here is the setup call:

    TWiki::Func::registerTagHandler( 'EMBED',   \&_EmBed );

and the actual routine:

sub _EmBed {
    my($session, $params, $theTopic, $theWeb) = @_;
    my($text);

    $text = $params->{_DEFAULT};

    $text = $session->handleCommonTags( $text, $theWeb, $theTopic );
    $text = $session->{renderer}->getRenderedVersion( $text, $theWeb, $theTopic );
    $text =~ s/[\r\n]+//sg;  # Remove all <cr>'s

#    print STDERR "Result[$text]\n";
    return($text);
} # _EmBed

Hope this works for you.

-- CraigMeyer - 11 Dec 2006

So...what became of this idea? Was it implemented? If so, where?

Thanks for your help!

-- SteveKelem - 2010-06-01

Nothing as far as I know. I invite you to get involved. Your contributions can make a difference. See ReadmeFirst.

-- PeterThoeny - 2010-06-02