https://bugzilla.wikimedia.org/show_bug.cgi?id=63324

--- Comment #10 from andré <and...@laposte.net> ---
(In reply to Brad Jorsch from comment #9)
> (In reply to andré from comment #8)
> > So you are saying that problems with the implementation of these new
> > features interfere with this extension ?
> 
> It's not a problem with those features, it's a design requirement.
> 
> We had to deal with that requirement when creating Scribunto, too.

Evidently.  And it works very well, at least on pages I've seen using it.  Such
modules can be a tremendous improvement over pure templates.

> > I'm assuming that all this extension does is scan the page, taking the
> > variable definitions and replacing all instances using the defined
> > variables, before any other parsing of the page.  The result is a page that
> > shows no evidence of the extension.
> 
> I haven't checked, but I'd imagine the model is more that when the parsing
> process calls the hook for #vardefine it sets some internal state, and when
> it calls the hook for #var then it returns that internal state. Much like
> how with Cite a <ref> sets some internal state and <references> uses that to
> construct a list of references.

It would be setting a value for a token, and replacing tokens with that value. 
Simple text replacement, as it passes through the page.  There are some more
complicated options, but they could be ignored by WP if difficult to implement.
 For instance, there could be a bar to using recursion.

> > Maybe there needs to be a processing priority established ?
> 
> Let's not add even more passes to the parser. The Parsoid folks already want
> to do that for Cite (and do do it in Parsoid).

But additional passes can be a very effective way of simplifying the problem. 
Often with little or no cost in performance.

> > Maybe you can explain how any problems with the new VisualEditor and Parsoid
> > are not orthogonal to this extension ?
> 
> Because wikitext needs to be parsed?

Logically, the simplest solution for extension:Variables is to have a priority
parsing pass to itself.  Once that is done, the resulting page shows no
evidence of the extension.
If there is a relatively straight-forward way to signal the use of the
extension in the page (such as a definition near the beginning of the page),
the performance hit for other pages should be minimal if any.
Maybe the parser could do an initial scan of the page to enumerate all the
extensions/modules used in the page (if it doesn't already), and then do
parsing passes according to an appropriate priority.  Many but not all could be
done in parallel.  Extension:Variables being an obvious exception.
It's not rocket science.  (To experienced programmers, at least.)

If there is a problem with how extension:Variables is implemented, I'd be
interested in writing a similar very simple equivalent, that does nothing more
than act as a preprocessor, replacing one or more variables with literal text
in a single pass.  In my mind that is all that most uses of such an extension
would be anyway.  And it does fill a void, between templates and modules
created with Scribuntu/Lua

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
_______________________________________________
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

Reply via email to