After looking at the implemention on test.wp.org , I am not pleased with how technical the code is, I strongly feel that its just a toy-idea.
I told gwicke on irc that I believe that sortable tables should come before timelines. Here is why:
First, 1.3 introduces a parser (Tim, (i assume), its a standard LALR algorithm that takes in a BNF grammar? (dont know where in the code it is exactly, both of these answers would help).
Assuming its a normal parser, then wiki tables will have to run through it no?
With this, just a little work is needed to make the tables into some type of data object that can be manipulated.
A simple application of this object would be making tables sortable on columns.
A more advanced application would be to take this object representing the tables and feed it to the timeline program (done in perl/plotticus). (I actually feel that it should be done in svg.... like the non-ganglia stats).
__________________________________ Do you Yahoo!? Yahoo! Movies - Buy advance tickets for 'Shrek 2' http://movies.yahoo.com/showtimes/movie?mid=1808405861
Hunter Peress wrote:
After looking at the implemention on test.wp.org , I am not pleased with how technical the code is, I strongly feel that its just a toy-idea.
I told gwicke on irc that I believe that sortable tables should come before timelines. Here is why:
First, 1.3 introduces a parser (Tim, (i assume), its a standard LALR algorithm that takes in a BNF grammar? (dont know where in the code it is exactly, both of these answers would help).
Assuming its a normal parser, then wiki tables will have to run through it no?
No, nothing like that. It's still essentially the same old parser. I moved it from OutputPage.php to Parser.php back in 1.2. It's based on multiple passes of preg_replace() for simple syntax, and preg_split() followed by simple processing of the split bits for more complex syntax. In 1.3, JeLuF introduced a tokenizer to handle internal links and apostrophe-based formatting. It runs through the tokens from start to finish in a single pass, maintaining modes, but it only handles a small portion of the wiki syntax. The code to split the tokens involves hard-coded regular expressions.
My brace-handling code is based on preg_replace_callback() instead of preg_split(), so it's rather inconsistent with the rest of the parser. I'd like to see it incorporated into the tokenizer section eventually. Presumably we could rewrite the entire parser properly in one go, but no-one has volunteered as of yet, and it's not clear what would happen to performance.
With this, just a little work is needed to make the tables into some type of data object that can be manipulated.
A simple application of this object would be making tables sortable on columns.
Alas no. The code for the wiki table markup is a pass where the text is split into an array of lines. It then loops through the lines, checking the first two characters and concatenating an appropriate segment to the accumulated string.
A more advanced application would be to take this object representing the tables and feed it to the timeline program (done in perl/plotticus). (I actually feel that it should be done in svg.... like the non-ganglia stats).
If we had an object to store tables, then sorting and manipulation of this kind would indeed be possible.
-- Tim Starling
On Thu, May 13, 2004 at 11:16:47AM +1000, Tim Starling wrote:
Presumably we could rewrite the entire parser properly in one go, but no-one has volunteered as of yet, and it's not clear what would happen to performance.
There's one in Ocaml I posted to wikitech-l some time ago. It wasn't complete, but nothing conceptualy difficult was left (HTML attributes validation and a few tweaks here and there). The problem is of course integrating such thing with PHP codebase.
Performance was excellent.
Tomasz Wegrzanowski wrote:
On Thu, May 13, 2004 at 11:16:47AM +1000, Tim Starling wrote:
Presumably we could rewrite the entire parser properly in one go, but no-one has volunteered as of yet, and it's not clear what would happen to performance.
There's one in Ocaml I posted to wikitech-l some time ago. It wasn't complete, but nothing conceptualy difficult was left (HTML attributes validation and a few tweaks here and there). The problem is of course integrating such thing with PHP codebase.
Performance was excellent.
I meant rewrite it in PHP. Lots of people have coded parsers in other languages, which aren't integrated with the existing PHP functionality: skins, title canonicalisation, link cache, user rendering preferences, etc. Not to mention more recent features such as template substitution and recursive parsing, TOC and section editing, wiki tables and hieroglyphics. Work on the PHP parser is continuous.
Theoretically we could write a PHP module to provide Ocaml integration. We would need some method for calling PHP from Ocaml also. Then the Ocaml parser could be dropped in. Perhaps it could then be used by MediaWiki users who want higher speed but less features.
Using Ocaml as the primary parser would mean more complex installation -- 5 packages to install instead of 4. Many web hosting companies provide PHP, MySQL and Apache but not Ocaml, so those users would be unable to install that version of MediaWiki. Also, most developers would have to learn the language.
In light of the costs, I'd have to see some very good reasons to switch to an Ocaml/PHP hybrid rather than continuing to work purely in PHP. The current PHP parser may be ugly, but it does work.
-- Tim Starling
On Wed, 2004-05-12 at 16:57 -0700, Hunter Peress wrote:
After looking at the implemention on test.wp.org , I am not pleased with how technical the code is, I strongly feel that its just a toy-idea.
I told gwicke on irc that I believe that sortable tables should come before timelines. Here is why:
First, 1.3 introduces a parser (Tim, (i assume), its a standard LALR algorithm that takes in a BNF grammar? (dont know where in the code it is exactly, both of these answers would help).
Assuming its a normal parser, then wiki tables will have to run through it no?
With this, just a little work is needed to make the tables into some type of data object that can be manipulated.
A simple application of this object would be making tables sortable on columns.
There are javascripts that do this, see http://plone.org/plone_javascripts.js, scroll down to 'table sorter script'. You can experiment with it in your user javascript on test.
Cheers
Gabriel Wicke
wikitech-l@lists.wikimedia.org