On 10-11-10 02:55 AM, Marco Schuster wrote:
On Wed, Nov 10, 2010 at 10:56 AM, Roan Kattouwroan.kattouw@gmail.com wrote:
We're not looking for a full-blown parser, just one that has a few basic features that we care about. The current JS "parser" only supports expansion of message parameters ($1, $2, ...), and we want {{PLURAL}} support too. AFAIK that's pretty much all we're gonna need. Michael Dale's implementation has $1 expansion and {{PLURAL}}, AFAIK, and maybe a few other features.
Actually PHP and JS are a bit similar. Different function names and slight syntax differences, but I think it is possible to take the existing PHP parser, strip out the references to MW internals and replace the database queries with appropriate API calls. That would also enable a "true" WYSIWYG editor or live preview at least, as having a JS parser will also allow that the resulting DOM nodes have some kind of "reference" attribute which can be looked at to find the wikitext responsible for the creation of the node (and so, enable inline editing). Actually, this seems just perfect for a GSoC project for next year: Port the MW parser to JavaScript, and a followup project to make a WYSIWYG/inline editor based on it.
Marco
Sorry, but the differences between PHP and JS are more than you think. Besides /x you're going to run into a bit of pain where /s is used. And you'll be rearanging code a bit to cache RegExp's created through string concatenation. And there's the potential to be tripped up by associative arrays if the parser uses them.
And as for WYSIWYG, parsing is quite different, at least if you're sane enough to not want to re-run an extremely expensive parser like the MW one for every few character changes. And then there are extensions...
The parser is heavy... even if you take into account how efficient JS engines have become and the potential for them to be even faster at executing the parser than php is you don't want a heavy directly ported parser doing the work handling message parsing client side.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]