On Wed, Nov 10, 2010 at 10:56 AM, Roan
Kattouw<roan.kattouw(a)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) [