On 10-11-10 02:55 AM, Marco Schuster wrote:
> On Wed, Nov 10, 2010 at 10:56 AM, Roan Kattouw<roan.katt...@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]


_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Reply via email to