Tables in Wikka
Table markup
(copied from WikkaDevelopment --NilsLindenberg)Richard Berg has provided code for very simple table code that could be placed in formatters/wakka.php. I think that one weakness that wikka has is the lack of support for any tables. Sure, I know people are thinking about syntax & extended features etc etc (I've contributed to that discussion) but I'd like to suggest that "simple" table support should be provided now if possible. Richard's code builds a table (and keep wikka links and formatting) using....
cell1 | cell2 | boldcell3 |
cell4 | cell5 | italicscell6 |
- (*Blush* OK, I was missing something. From my early days with Wikka, I remembered having seen an "awkward table markup", and (much) later found a table action; the result: I thought we had both. In reality, the "awkward markup" I remembered was the action. I'll refactor the stuff below somewhat in view of this.)
The problem is not that Wikka has "lack of support for any tables" - we have a table action that serves as a "poor man's table markup". The real problems with this are:
- this table "markup" (action) is basic, but at the same time very difficult to use (because it's really an action, and also because it's different from the common approach to table markup in many Wikis)
- the table "markup" (action) does not support Wikka markup within its cells
- it does not actually produce data table markup (which it should)
- In my opinion, we should carefully determine what we want to be able to do in terms of table markup, and then look if we can find a simpler preliminary solution (a subset) that still enables us to get there. And any preliminary solution should at least address the problem of ease-of-use and generating data table markup.
Even more preliminary, I suspect that it would be possible to make our current table "markup" (action) support Wikka markup within the cells by making a change to how the Formatter processes a page - this should already address a major drawback of what we currently have and give us some breathing space to come up with a different, better markup. --JavaWoman
- It was unfair of me to say that we don't have "any table support"....there's both the action & html markup....I meant wikka-markup table support that is simple and straightforward to use by "real" people (as opposed to us). Anyhow, I should, in fairness, point out that Richard's code has limitations. You can't put it around ===header=== code, @@centering@@ breaks the interpreter, there must be a blank line after the table code or it causes a real mess, and you can't escape the double pipings/table using double quotes (which I do find irritating....this is probably all easily solvable....just not by me I'm afraid). If anybody wants to "play" go here. -- GmBowen
- Sorry for butting in; I've modified my wakka formatter to handle SimpleTables with the markup "||" for delimiter. It is escaped by two double quotes, and handles other wiki markup pretty well. Should solve GmBowens problems. This is a code modification. Free for all to use as they see fit ;) --TormodHaugen
- If you want to include HTML markup, then yes we have two methods - but I wan't considering HTML markup; but the major drawback of our current table "markup" (action) is that we can't have Wikka markup inside the cells. So I'll see if that can be resolved first. I'm not considering any alternative markup until we have a plan for what we actually want to be able to support. A preliminary solution that may have to be thrown away again later because it doesn't lead to where we want to end up will just lead to endless confusion and waste a lot of effort. (Meanwhile, if Richard's code works for you, I won't stop you using it. ;-)) --JavaWoman
- On further investigation, I found it's actually very simple to change the {{table}} action (pseudo-markup) so that it does support Wikka markup within the cells. In fact, nearly done, and I may come up with a version that does headers (th) as well. That should tide us over until we have decided on a direction for table markup. --JavaWoman
- Well, scratch "very simple" and make that "reasonably simple" but I've done it. And documented it, of course. My re-write of table action is presented on the TableAction page, with documentation and examples on the TableActionInfo page. Please test thoroughly! --JavaWoman
Editable tables
I don't know if this goes against the Wiki way of doing things, but it would be nice to configure a table in which users could enter data into and then 'submit' (click a submit button I suppose) and have it saved to the page without having to 'edit page'.--ArisStathakis
Can you post a link to a site where you can enter data without editing the page? I'm not sure what that would look like. - JsnX
GmBowen had something related (I've inserted a link to a screen capture of it in action). I can't seem to get his page to load, therefore I've linked it to its google-cache. Basically, it's a form input thing that allows you to create tables row by row and edit data cell by cell. Very tedious to initialise, (not really, just {{spreadsheet}} starts it, and then you enter rows and columns of data almost like you would in a spreadsheet -- Mike) but i suppose it could be handy just to click on celldata to edit it (and view data if the user has readonly access). This method is a lot more intuitive than the current method of creating tables, but it would involve flatdb (or a new/seperate mysql schema). Just adding to the discussion, I don't believe that this suggestion is the ultimate solution. -- Sam .....this is coming along, but having issues with re-saving with a different name. Functions all work now & refresh automatically. Script works well with individual spreadsheet. Right now, working on it so that user can have one page where all spreadsheets can be managed, and then a user can insert any of their spreadsheets anywhere using an {{inserttable}} action (and you can set function results on or off).....
http://gmbowen.educ.unb.ca/wikitest/inserttable.jpg
The "spreadsheet" (or, interactive table if you want) script uses a MYSQL table with the spreadsheet assigned by default to the page name & owner (which has to match the logged in user), although the logged in user can "force" another table name. Another "action" script allows just showing the table without the interactive nature. So the user can enter the table components using the "spreadsheet", and then show it on the page using the "showtable name=" script. The spreadsheet script allows one to calculate sum, average, count, and frequency (at this point only on the columns) and is intended to provide simple on-line spreadsheet functions for kids working on science projects which they can then embed in a written report. I'm moving the server right now which is why it isn't up. It will be in the next week. The script is a (greatly) modified version of one available from this site...http://www.ka.sara.nl/home/boven/ .... Because it's intended for kids it is reasonably user friendly, although lacking many formatting abilities that "adult" users are used to -- Mike Bowen
My 2 cents on tables. I think we should consider in the long run the possibility of a major refactoring of the syntax for tabular data. The current table action is extremely user-unfriendly (just have a look at the source of ConfigurationOptions). Moreover, the table action does not convert wikka-formatted strings, which in some cases is a little annoying. It think a nice idea would be to have tables directly handled in the formatter, instead of using an action. I like very much the wacko approach to tables, maybe we could do even better and find a more intuitive syntax. -- DarTar
I haven't checked this out yet, but doesn't UsingHTML pretty much solve the problem on table syntax? Now it's just figuring out how to edit a cell without editting a page. --Sam
If you want to work with individual cells, it sounds like you're thinking about something like this.... http://www.ycode.com/SpreadSheet/Latest/yCode_spreadSheet_simple.htm ... although it is not open source. Just providing the link for discussion purposes. -- Mike B
Tables were one of the biggest reasons for us wanting to go with Wikka over our existing WakkaWiki. However the syntax as it is right now is pretty unintuitive. Having one giant string of comma separated values just doesn't work for me. It would be nice to at least make it so you can add line breaks between rows. -- Justin F
FlexWiki* has a rich table markup that seems fairly easy to use. See FormattingRules for the basics and TableFormattingRules for the details. I'd like us to adopt at least the basics, and maybe add some of the extended possibilities gradually.
* (MS open source! And with Ward Cunningham apparently working for MS now...)
--JavaWoman
- JW, an interesting syntax for tabular data is used by CitiWiki (adapted from ComaWiki): HelpMeTable -- DarTar
- DT, JW, JT etc....if you "like" the table format used by CitiWiki (and I personally think it's reasonably user friendly & a good alternative), I might suggest not looking at the code at all but trying to replicate the outcome using your own coding approach. Rightly or wrongly, ComaWiki is copyrighted...at least the "new" parts are....and not released to public domain (he charges for commercial use), so using (and, in legal cases, even looking at somebodies code makes you culpable is my understanding) the code as part of wikka might lead to problems. Just food for thought. --GmBowen
- Hmmm - the CitiWiki syntax looks very much like FlexWiki as far as the basic syntax is concerned - but the complete FlexiWiki table syntax is not only richer, but it's syntax "pattern" is more easily extensible, too. Do have a look and compare what they do with CitiWiki and you'll (probably) see what I mean. :) I like extensibility so I like the FlexiWiki syntax better. No problems with copyright either - it's open source.
- In fact, since I expect I'll need tables for my (planned) Wiki I'd do my own mod for this if Wikka doesn't have one by the time I get may email stuff finished (hacking hard...). -- JavaWoman
- I put a link on the CodeContributions page to code developed to do tables in wikini that provides formattable tables....since they and we are both wakka forks maybe the code would easily transfer to wikka.....or we could build on it to provide the functionality that people need/want. -- GmBowen
- Mike, that Japanese wiki you had up the other day (still?) also has nice table markup - somewhat simpler than FlexWiki but it could also be a start. Do you have a download link for it? I'd like to have a look at their code. --JavaWoman Their sourceforge site is http://pukiwiki.sourceforge.jp/ .... somehow I got it from there. I'm nowhere near the machine that the zip is on.....but I'm sure you can get it from their sourceforge site. Hope that helps.....oops, found it on their main site....http://prdownloads.sourceforge.jp/pukiwiki/10732/pukiwiki-1.4.4.zip. -- mb
- Got it - thanks Mike! --JW
Picking up on Sam's point....perhaps code written for wikka that does something like this.....
http://131.202.167.33/wiki/wakka.php?wakka=TableMaker -- GmBowen [note: This is a modified version of the linked page which replaces Dave's tablemaking code with the nice blue colors (see comments at bottom of page) with the "freely available" code from http://javascript.internet.com/ without the nice blue colors....and which describes it's code as "The script is yours!" when you access the source code....so shouldn't be any problems now folks]
All that to generate a very basic HTML table (not even a data table)? A good Wiki syntax would probably be easier to understand as well as more efficient for the basics. -- JavaWoman
Like JavaWoman, I use tables frequently, to the point that ugly is better than nothing. I upgraded to Wikka for the inline images...as a longtime user of Wakka, I had concocted just such an ugly hack:
if( !function_exists('tableize') )
{
function tableize($txt)
{
$rows = preg_replace('/\|\|(.*)\|\|/', '<tr><td>\1</td></tr>', $txt[0]);
return '<table border="1">'.str_replace('||', '</td><td>', $rows).'</table>';
}
}
$text = preg_replace_callback("/((?>(?=^\|\|.*?\|\|$)^.*?$\n?)+)/sm", 'tableize', $text);
{
function tableize($txt)
{
$rows = preg_replace('/\|\|(.*)\|\|/', '<tr><td>\1</td></tr>', $txt[0]);
return '<table border="1">'.str_replace('||', '</td><td>', $rows).'</table>';
}
}
$text = preg_replace_callback("/((?>(?=^\|\|.*?\|\|$)^.*?$\n?)+)/sm", 'tableize', $text);
Unfortunately, inserting it near the bottom of /formatters/wakka.php doesn't seem to work as it did in Wakka, and since I only wrote this with the aid of PHP-literate friends, I have no Wikka solution at this time. A simple regex like this isn't sufficient to develop the extensible syntax seen in FlexWiki, but I have a feeling if someone noticed the (probably obvious) incompatibility that it would be a nice holdover for JW and myself. For the future, I definitely agree that a FW-style syntax is necessary; spreadsheet abilities like in Mike B's link would be orgasmic, even if they represented a completely different feature from regular tables. -- RichardBerg
I've tried inserting this also with no luck. However, it now seems to work quite nicely at Richard's home site. For me, simple to use tables now are much more useful/important than much better tables later (I've got a class using this that I want tabularized time-trial information posted bi-weekly). Can any of the guru's here take a stab at getting this simple approach to tables working...at least "for now"? Thanks. -- GmBowen
It does not actually work at my site either, G. That page was rendered in the Wakka days; if you edited it and clicked 'store,' it would fail just like all my more recent pages. Good news, however -- while the regex above is still illegible to me, I decided to see if I could write my own. Here's a first effort (stick it right before the main preg_replace_callback):
(removed, see below)
The good: it works.
The bad: $wakka->SafeHTML doesn't like it. I'm not sure why -- W3C's validator says the output has no errors -- but for now you have to turn it off.
Also, you must have a blank line after a table!!! (very important)
(I forget whether the previous code had this limitation). I'll see if I can fix these things, but I know GmBowen wanted something quickly. -- RichardBerg
Update: here's a version that goes after the main regex. That makes it even uglier and less extensible, but you can use it without raw HTML (or any HTML setting at all; no safety checks, though it does pass W3C).
// horrible ugly table hack v2.0
if( !function_exists('quicktable') )
{
function quicktable($txt)
{
$temp = $txt[0];
$temp = "<table border='1'>\n".$temp;
$temp = preg_replace("/^\|\|(.*?)\|\|\<br \/\>$/m", "<tr><td>$1</td></tr>", $temp);
$temp = str_replace("||", "</td><td>", $temp);
$temp = str_replace("<br />", "", $temp);
$temp = $temp."</table>\n<br />";
return $temp;
}
}
$text = preg_replace_callback("/^\|\|(.*?)\|\|\<br \/\>\n\<br \/\>$/sm", "quicktable", $text);
if( !function_exists('quicktable') )
{
function quicktable($txt)
{
$temp = $txt[0];
$temp = "<table border='1'>\n".$temp;
$temp = preg_replace("/^\|\|(.*?)\|\|\<br \/\>$/m", "<tr><td>$1</td></tr>", $temp);
$temp = str_replace("||", "</td><td>", $temp);
$temp = str_replace("<br />", "", $temp);
$temp = $temp."</table>\n<br />";
return $temp;
}
}
$text = preg_replace_callback("/^\|\|(.*?)\|\|\<br \/\>\n\<br \/\>$/sm", "quicktable", $text);
Hi Richard. Thanks for posting this. Sadly :( I still can't get it working. (i) Do you still have to "turn off" $this->safehtml. If so, how? (ii) could you be more specific wrt where to put the code? I'm assuming formatters/wakka.php is the file to modify, and I tried it in several places at the end of the file, but no luck. Do you have to comment out any other lines? Thanks. -- GmBowen (aka Mike).
Mike, here's the file: http://richardberg.net/bin/temp/wakka.php.txt - you'll see that safehtml is still enabled (my previous short-circuit is commented out) --RichardBerg
Thanks Richard, works like a charm. What's weird, is I cannot see what is any different than what I did. Oh well, it's working now at least.
For a further addition to the resources here for table markup.....there is a code contribution at http://www.wikini.net/wakka.php?wiki=ReglesFormatageTableau by DavidDecotigny that works quite well in wikka (tested in both an earlier and the most recent version) IF $wiki->Format is changed to $wakka->Format in the code....and it's quite easy to add the code to wikka (it took me 10 minutes to install it and get it working, and that includes figuring out the small code change necessary). (Note: David didn't leave any instructions for copyright in his code, so I'm not comfortable posting it here.) -- GmBowen
- Unfortunately, although it pretends to (be able to) generate table headers, what it actually does is make some datacell content bold (and not even <strong>). Any table markup syntax we adopt should be capable at least to generate real data tables, not layout tables. The markup shown here would at least have some of that capability, but the code that is actually generated is not a data table at all. --JavaWoman
- Oh, point taken. Absolutely....in fact the code submission at wikini was only a suggestion for table markup (I guess wikini doesn't have table markup yet either). I wasn't actually referring to this page with an implicit suggestion that we adopt it as the official table markup approach for wikka....I know that's still in discussion and that this doesn't meet the earlier stipulated criteria. However, there are some wikka users who have voiced (and probably others who have not) a desire for simple table markup RFN....and for me this code solves a big issue. So, if somebody really wants markup right now, then this is a solution....and an improved one over RichardBerg's code above (sorry Richard) because it doesn't have the restrictions around it (as listed farther above) and can also have some "aesthetic" formatting associated with it through the css. --GmBowen
- It could be a (limited) solution if the generating code would actually generate table headers instead of bold content. But if the resulting HTML markup isn't structural, then CSS "aesthetics" won't help to make the result structural, let alone make it even a bit accessible. The wiki markup shown is a good start at least (and indeed simple), but the code generating script completely misses the mark. Sorry, Mike, it doesn't solve a big issue, not even for you, I promise: it creates one. --JavaWoman
- Um, and the code doesn't actually generate bold (fake) headers either...he just did it with the double-star bold markup code. It'd be better if it did generate table header code, and I've looked at the code to try and figure out how to get it to do that, but frankly because it's in French I haven't been able to figure it out at all. Real table headers would be preferential for me because one could then have a different colour for the header background than for the alternating rows beneath. --GmBowen
- What I'm saying is the script doesn't generate table headers at all, only content (data cells). But have a look at what my emhanced tabel action is doing - it's taking cell content in ==...== and turns that into table header cells; the same could apply to cells with **...**. Except I think using ==...== would be more "intuitive" and would also allow you to have datacells with bold content (as my tabel action does). And you're right that with true header cells, you can do a lot nicer styling, too. Take most of their code, and a pinch of mine, stire well, bake for an hour, and you might have something primitive but actually usable ;-) --JavaWoman
CategoryDevelopmentFormatters