Change 999718 had a related patch set uploaded (by Sergio Gimeno; author: Sergio Gimeno):

[mediawiki/extensions/CommunityConfiguration@master] Add editor special page

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

Change 994787 had a related patch set uploaded (by Sergio Gimeno; author: Sergio Gimeno):

[mediawiki/extensions/CommunityConfiguration@master] Add editor special page

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

Change 1004306 had a related patch set uploaded (by Sergio Gimeno; author: Sergio Gimeno):

[mediawiki/extensions/CommunityConfiguration@master] [WIP][DNM] Editor: add initial form builder

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

Change 1004338 had a related patch set uploaded (by Sergio Gimeno; author: Sergio Gimeno):

[mediawiki/extensions/CommunityConfiguration@master] [WIP][DNM] Editor: add control for string types

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

Change 999718 abandoned by Sergio Gimeno:

[mediawiki/extensions/CommunityConfiguration@master] Add editor special page

Reason:

Reworked in I7e89f3e275a19480b42bbc46fcd37d269c7b50ea

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

Change 1005152 had a related patch set uploaded (by Sergio Gimeno; author: Sergio Gimeno):

[mediawiki/extensions/CommunityConfiguration@master] [WIP] Editor: add i18n support for control labels

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

Change 1005459 had a related patch set uploaded (by Sergio Gimeno; author: Sergio Gimeno):

[mediawiki/extensions/CommunityConfiguration@master] [WIP][DNM] Editor: add control for number types

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

Implementation notes

General architecture
The editor form is displayed on a Special page (CommunityConfigurationEditor) in the url Special:CommunityConfiguration/<provider_name>. The server provides the schema, config data and general config as JsConfigVars in communityConfigurationData. The form is 100% built on the client by the ext.communityConfiguration.Editor module. The module consists of two main components:

• The "editor application" ( in ./App.vue)
• The "json-form" library under ./lib/json-form, which consists of three components as well
  • The core functions to manipulate and transform the JSON schema, the control ranking system and localization ./lib/json-form/core
  • A set of Vue components needed for generating an HTML form based on a given schema and set of controls ./lib/json-form/form
  • A set of controls made with Vue/Codex components to align the rendered form with MW design style guide ./lib/json-form/controls-codex

Application

Responsible for loading the schema and config data from the server. Responsible of pulling the translations required for the from from the MW messages API (although this could change in the future and be done by the server if deriving a list of translations from a schema is possible). Responsible of loading the custom controls from a given provider. It boots a Vue application instantiating a JsonForm component with mentioned props.

JsonForm
Responsible for creating a form layout and displaying the appropriate control (based on their ranking score) for each configuration found in the schema. In the future can hold other form representation aspects as the grouping of elements and other customisations.

Codex controls
Set of controls to render JSON schema types such as boolean, string, numbers, enumerations, etc. The goal of the collection is not to cover all of JSON schema vocabulary which is vast neither to provide custom representation of types. The collection is focused on providing appropriate defaults for rendering most commonly used types. The final list is yet to be determined.

Open questions

• Should we move the json-form logic to another repository?
• Should we compile the json-form code?
• How should consumers register their own form?
• How should consumers register their own controls?
• What is the most appropriate i18n strategy for consumers to register (or not) translations? Which component should be responsible of providing these?
• A "reducing" strategy is needed to display several data in the form based on the schema and the form state, eg: validation messages like "The minimum length for this field is 16 characters". Does it make sense to use Vuex for this? Or should we stick to a Vue-agnostic state management solution?

Change 994787 merged by jenkins-bot:

[mediawiki/extensions/CommunityConfiguration@master] Add editor special page

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

Change 1007943 had a related patch set uploaded (by Sergio Gimeno; author: Sergio Gimeno):

[mediawiki/extensions/CommunityConfiguration@master] Editor: send new config data on form submision

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

Change 1008423 had a related patch set uploaded (by Sergio Gimeno; author: Sergio Gimeno):

[mediawiki/extensions/CommunityConfiguration@master] Editor: add control for object type

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

Development summary

The editing form MVP is an initial implementation of the editing form specification in T343072. Patches under the form-generation-special topic should provide a functional prototype of the community configuration editor. Below is a map of the editing form concepts from the specification to components (as in software components, not all of the concepts are represented by a single Vue component).

• json-form/core responsible of Localization and Validation. Validation support is limited to required fields, not other constraints (eg: minimal value). UISchema abstraction is intentionally not exposed yet but is the internal data structure that represents the form UI.
• json-form/form responsible of rendering the form Layout based on a given schema. No field grouping or categorization support yet (T358221).
• json-form/codex-controls responsible for providing default Codex Controls for the supported JSON schema types.
• App.vue responsible for loading the schema data from the server and performing the data submission through the edit API (T357531). It also holds the full application and form state.

Rules and Customisation features are left out of the MVP.

Open questions answers

• Should we move the json-form logic to another repository? Since the only consumer of the json-form library at this point is CommunityConfiguration this is not needed now.
• Should we compile the json-form code? So far it is small enough to be shipped as separate scripts but if it grows it could be considered
• How should consumers register their own form? Not yet decided but probably adding a different "form" type in their CC provider
• How should consumers register their own controls? PoC in 1005831
• What is the most appropriate i18n strategy for consumers to register (or not) translations? Which component should be responsible of providing these? So far json-form will provide a "framework" for field labels and help texts. That means it will generate conventional named keys for common field text. Custom control renderers will require to load their own dedicated text keys via RL module.
• A "reducing" strategy is needed to display several data in the form based on the schema and the form state, eg: validation messages like "The minimum length for this field is 16 characters". Does it make sense to use Vuex for this? Or should we stick to a Vue-agnostic state management solution? So far the editing form MVP has been implemented without dedicated state manager solution. That means it uses Vue reactive primitives (ref, reactive) to hold a single deeply reactive object to hold all the form state. If state management does not become over complicated, avoiding to use an external dependency sounds good for keeping asset payloads smaller.

Change 1004306 merged by jenkins-bot:

[mediawiki/extensions/CommunityConfiguration@master] Editor: add initial form builder

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

Change 1004338 merged by jenkins-bot:

[mediawiki/extensions/CommunityConfiguration@master] Editor: add control for string types

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

Change 1005459 merged by jenkins-bot:

[mediawiki/extensions/CommunityConfiguration@master] Editor: add control for number types

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

Change 1007943 merged by jenkins-bot:

[mediawiki/extensions/CommunityConfiguration@master] Editor: send new config data on form submision

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

Change 1005152 merged by jenkins-bot:

[mediawiki/extensions/CommunityConfiguration@master] Editor: add i18n support for labels and help text

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

In T356622#9596438, @Sgs wrote:

• json-form/core responsible of Localization and Validation. Validation support is limited to required fields, not other constraints (eg: minimal value). UISchema abstraction is intentionally not exposed yet but is the internal data structure that represents the form UI.

@Sgs - presently it's easy to get communityconfiguration-schema-validation-error on wiki/Special:CommunityConfiguration/FooBar. Two issues

• the Submit button is always active - it's displayed active on the initial page load and it's still active regardless of user's input
• the lack of warning/guidance to users on non-valid input

I also looked T343072: Community configuration: Write specifications for the Editing form for validation specs:

Validation: responsible for ensuring submitted data is valid. Aside from the schema validation that will happen on the backend after form data is submitted the auto-generated form should have client validation that helps users fill in the form. Form validity is expected before sending data to the server (and possibly schema validity). Ideally the UI should be capable of showing validation errors in real-time, when the user fills in a field.

Would validation/error handling specs be added later? Is the present form can be tested for validation?

Change #1008423 merged by jenkins-bot:

[mediawiki/extensions/CommunityConfiguration@master] Editor: add control for object type

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

In T356622#9644577, @Etonkovidova wrote:

@Sgs - presently it's easy to get communityconfiguration-schema-validation-error on wiki/Special:CommunityConfiguration/FooBar.

Thanks for testing! Could you provide the data input which you used when those errors occured?

Two issues

• the Submit button is always active - it's displayed active on the initial page load and it's still active regardless of user's input

Yes, this behavior is expected per design guidelines in validation

• the lack of warning/guidance to users on non-valid input

We will work this particular problem in T358659. Could you share which kind of invalid input did you try?

I also looked T343072: Community configuration: Write specifications for the Editing form for validation specs:

Validation: responsible for ensuring submitted data is valid. Aside from the schema validation that will happen on the backend after form data is submitted the auto-generated form should have client validation that helps users fill in the form. Form validity is expected before sending data to the server (and possibly schema validity). Ideally the UI should be capable of showing validation errors in real-time, when the user fills in a field.

Would validation/error handling specs be added later? Is the present form can be tested for validation?

The validation specs will be implemented in T358659.

Thx @Sgs for the comment above! I added the cases for invalid input in T361324 (as #1) - they are relatively minor, i.e not disrupting or impacting the functionality. I've reviewed the scope of this task (User story and Developer story) - the scope is done, as for a MVP. The provider part was checked locally (e.g. for an invalid).