Page MenuHomePhabricator

Information can be passed between #invoke's (tracking)
Open, HighPublic

Description

This bug lists as dependencies all bugs that allow information to be passed between different calls to #invoke on the same page.


Version: unspecified
Severity: normal

Details

Reference
bz65258

Event Timeline

bzimport raised the priority of this task from to High.Nov 22 2014, 3:24 AM
bzimport set Reference to bz65258.
bzimport added a subscriber: Unknown Object (MLST).

Hi, this is bugs, I'd like that this was a feature ...

Explanation : We use lua and Wikidata to generate datas for example in this page : https://fr.wikipedia.org/wiki/Comparaison_de_WAMP
The problem is that the same source is used several times in different Wikidata claims, and that leads to duplicate references in the reference section.

We need to track references usage in the whole page, and this is currently not possible. Is this going to be ? Where should I ask for a feature request ?

Parsoid requires that each call to #invoke does not depend on anything else on the page, so it can parse the wikitext piecemeal.

I do not want disturb this task. But to manage versions of a group of submodules inside one main module, I use package.loader and _G space to coordinate them and change, if it exits, the version of each submodule sought by the main module.

Here we could imagine a space dedicated to the intermodules communications across an _I intermodule space, without disturbing the parser which receive the results of modules in the page order. An whitout use any thread task.

This _I space could permit to re-use: a research in wikidata, a complex or heavy computing...
Used also to build and enhanse, step by step, a collection of references or linked articles...

Parsoid requires that each call to #invoke does not depend on anything else on the page, so it can parse the wikitext piecemeal.

How does that work for the bibliography section ? It seems that that section has to depend on a lot on stuff in the page. Could we imagine a similar mechanism here ?

Here we could imagine a space dedicated to the intermodules communications across an _I intermodule space, without disturbing the parser which receive the results of modules in the page order. An whitout use any thread task.

You seem to have completely missed the point. If a second invoke's behavior changes depending on what was done in the first, how then can Parsoid process only the second? One of the long-term goals for Parsoid is to be able to reparse only the part of the page that was actually changed and then merge it into the existing HTML for the rest of the page.

How does that work for the bibliography section ? It seems that that section has to depend on a lot on stuff in the page. Could we imagine a similar mechanism here ?

If you're referring to the Cite extension's <ref> and <references> tags, Parsoid reimplemented those in nodejs so it can track the dependencies. And I suspect that only works because expandtemplates doesn't process extension tags like <ref>, while it does process parser functions like {{#invoke:}} which would make things that much harder.

You are right. Rest only the re-use of a research in wikidata, perhaps in several pages of wikidata, or of a complex and heavy computing...

Hello, I landed here after an answer to [[Wikitech-l] Is it possible to edit scribunto data module content through template edit popup of visual editor?](https://lists.wikimedia.org/pipermail/wikitech-l/2017-September/088773.html)

I'm not sure to understand the issue tracked here, and how it might conflict, as it was stated in the answer leading here.

My current analyse of requirements for the project I have in mind would be to be able, from a scribunto script, to save data in a scribunto data module. This save operation might be hugely limited to avoid any technical risk/problem expected.

To sketch the need I want that in wiki article one might write {{description|term=Anomie|definition=An awesome guy}} and when saving the page, the wikicode become {{description|term=Anomie}} and the page display An awesome guy. And under the wood, the template invoke Module:description with all the given parameter received (and possibly more). This module would do something like

  • local data = mw.loadData( 'Module:Description/data/Anomie' )
  • check if a definition parameter was filled
    • if so, update the matching variable and do something like mw.saveData( 'Module:Description/data/Anomie', data)
  • return the description matching the passed criteria

Would that be a "no way" scenario such as this ticket is trying to prevent?

Leaving aside how bad of an idea that proposal is for other reasons, the problem specific to this task would be that one #invoke could do your mw.saveData and then another #invoke could load that file and read what the first one saved.

What can we share between #invokes?
Images from Commons, items from Wikibase,
templates, modules and submodules from Scribunto.

These pieces go into the cache, collected by the parser along the interpretation
and along the running of modules or templates.

If the same module or template is called some times with exactly the same arguments, we could reuse their results.
In any other cases, modules and templates running are too complex to reuse their results.

What else?

@Rical: You seem to be misunderstanding the point of this bug. This is not about what we can cache.

If the same module or template is called some times with exactly the same arguments, we could reuse their results.

The point of this bug is to track things that would prevent that.

Chinese Wikipedia currently has a module that implements a functionality similar to Extension:Variables. See https://zh.wikipedia.org/wiki/Module:Var