Page MenuHomePhabricator

Design new VisualEditor template dialog data model and data propagation
Closed, ResolvedPublic8 Estimated Story Points

Description

We want to start by designing a data model that can be shared between both the sidebar and the content pane.

  • Lists top-level content elements (can be multiple templates as well as wikitext snippets).
  • Lists all known parameters.
  • Each parameter with a bool flag for the checkbox.
  • Unknown parameters can be added any time.
  • Search indexes (many TemplateData fields)
  • Need to consider the event handling model--possibly a merged data structure is not going to be easy.
  • Draw a diagram of the data container(s) and how changes are propagated among components.

We’re worried that the content model is designed to be 1:1 with wikitext, and our model which contains nonexistent parameters will break this assumption.

Updates are currently propagated by add, remove, and replace events. Will we stay in this paradigm? The alternative is to send something like a "change" event, and each pane is responsible for updating itself from the master data store.

Related Objects

StatusSubtypeAssignedTask
OpenNone
ResolvedWMDE-Fisch
ResolvedWMDE-Fisch
ResolvedAndrew-WMDE
ResolvedWMDE-Fisch
ResolvedAndrew-WMDE
ResolvedBUG REPORTawight
OpenNone
OpenNone
ResolvedNone
InvalidNone
Resolvedthiemowmde
ResolvedAndrew-WMDE
ResolvedNone
ResolvedNone
Resolvedthiemowmde
ResolvedAndrew-WMDE
ResolvedWMDE-Fisch
ResolvedLena_WMDE
ResolvedNone
ResolvedECohen_WMDE
OpenNone

Event Timeline

Change 667892 had a related patch set uploaded (by Ebernhardson; owner: Ebernhardson):
[wikimedia/discovery/analytics@master] ores_bulk_ingest: Increase drafttopic error_threshold to 1 per 500

https://gerrit.wikimedia.org/r/667892

awight set the point value for this task to 8.Mar 3 2021, 1:41 PM
awight renamed this task from Design new VisualEditor template dialog data model to Design new VisualEditor template dialog data model and data propagation.May 14 2021, 7:43 AM

Today's thoughts:

  • BookletLayout embeds assumptions about data flow and the relationship of its "outline" to the content, which are not compatible with the new design.
    • We need to rewrite the hierarchy from this level down.
    • "TransclusionEditor" will contain a "TransclusionOutline" sidebar, and a "TransclusionContent" main pane.
    • The content pane classes will be mostly unchanged, with one exception: they currently have responsibility for creating their own outline items. This code will become inert in the new hierarchy, and will only be used for legacy BookletLayout invocations in other extensions.
    • The sidebar classes are replaced.
  • We can use the transclusionModel (interface to the wikitext being edited) as our main source of truth. For example: let's take the UI action to delete a parameter. This will call transclusionModel.disconnect, and a replacePart(removed, null) event is emitted.
  • The sidebar and content panes listen to the wikitext, and add or remove UI elements in response to changes. This approach is already a partial precedent in existing code, but I'm recommending that we consolidate to this approach and migrate any data flows going through other objects.
  • Parameter order follows the existing rules. Wikitext order may vary, and is kept stable during normal edits, but dialog order is always canonical. Unknown parameters come last, in the order dded. In other words, nothing changes here.
    • The canonical ordering service can be extracted into a module, which reads from the template spec and from the transclusionModel. It could be implemented by listening to transclusionModel changes.
  • The template spec holds the list of "known" parameters and should be constant during the course of a dialog.

Search indexing is still an open question, I would like to use the same transclusionModel-driven flow, but it looks like we need some awkward routing to split events by which multi-part template they belong to, for both search and the sidebar?

Still need to draw this proposal.

Today's thoughts:

After a quick Dev Talk, this theory seems reasonable enough to move forward with. Please jump in with any last concerns you might have!

Lena_WMDE claimed this task.