FrontPage RecentChanges AboutWikiFeatures WikiNode

TableEditing

/!\ This idea is still in discussion, and does not meet the FeatureTemplate yet.

/!\ We can check it off on IdeasToPlace, after we wrap this up into a FeatureTemplate page, and after we write it up in FeatureSummaries.

One of the page elements that often get difficult to edit (due to the choosen markup and content size) are tables. A specialized editing capability (a bit like WysiwygEditor) would allow easy modification of table cells. An example is available at ErfurtWiki:TableEditorMarioSalzer

Wow! I had just come to make such an entry..!

Some see also’s, before I get into it:


ThomasWaldmann & I recently talking in CommunityWiki:IrcChannel about table syntaxes.

I think we should use a hybrid model, between what we have now, and the ability to “paint” into the table. Also, want to be able to “call out” sections of the table.

We have now:

| name | favorite color | description |
| Lion | yellow | Friendly programmer. |
| Kitty | red | Friendly snowboarder. |

While still having that old form, (or something like it,) we could also support:

*table*
| name | favorite color | description |
| Lion | yellow | *REF1* |
| Kitty | red | Friendly Snowboarder. |
*REF1*
Lion's this guy.

Here's a picture of him:

http://speakeasy.org/~lion/lion_positive2.jpg
*/table*

And, even further afield, we could have:

*table*
| name | favorite color | description |
| Lion | yellow | |
| Kitty | red | Friendly Snowboarder. |
*3,2*
Lion's this guy.

...
*/table*

or even

*table*
*1,1* name
*2,1* favorite color
*3,1* description
*1,2* Lion
*2,2* yellow
*2,3*
blahblahblah
...and so on and so forth...

or even

*table*
*table-COLUMNS*
Favorite Color
Description
*table-ROWS*
Lion
Kitty
*Lion,Favorite Color*
Yellow
*Lion,Description*
blahblah
blah
*Kitty,Favorite Color*
Red
*Kitty,Description*
Friendly snowboarder.
*/table*

So, you could have a mix of representing and painting into the table.

LionKimbro 2004-03-27

… - I wouldn’t even bind those two ideas to tables only. While background painting makes most sense for tables, people may want to do this for lists or paragraphes also.

That’s why my engine (ErfurtWiki) supports full CssInjection support - you know CSS is purely presentational and cannot be a security risk. But then it allows you to set background and foreground colours, font names, font size, borders and so on. And all this by just one additional markup. I haven’t completed that, but if it works (currently using the not so well thought “@@” for starting a CSS definition) I’d just write:

<code>{{{
  |@@background:#ff5555  cell1  |@@color:#000055  cell2   |
  | cell3 with ordinary text    |@@font:Verdana   cell4   |
}}}</code>

That would work for lists and text paragraphes too. Likewise the table references idea (here text) could be expanded to a general “ContentReferences” feature. For the tables it generally makes of course most sense, because you could this way insert lists or subtables into table cells (which is impossible with most current table markup).

For example:

<code>{{{
  %%REF1%% = <<<EOT
* I'm a list
* with two __points__
EOT

| a table | with pre-rendered subelements |
| for example:  |  %%REF1%%  |
| or even:      |  %%REF2%%  |

%%REF2%% = <<<EOT
| this | becomes  |
| a | subtable |
EOT
}}}</code>

Think, this could be unlimetedly nested. Also refernces could be defined on other pages: %%SeeHere/REF2%% - or simply other pages could be referenced into another pages table: %%SubPageWithTable%%

<note>Engines would search for m/=\s*<<<\s*(\w+)(.+?)(\n\1)/ then, so you could
use %%REF%% or $REF$ or *REF*</note>

MarioSalzer time(1080483351)

See Also: TransClusion