New Wizarding: User Requirements

[trusz]

🚧 Work In Progress

Summary

In this issue we list the initial user requirements of wizarding API.

Users

We have the following groups that use wizards:

• end-users: they use the wizards in OpenSCD
• wizard authors: the people that creates the wizards
• plugin authors: who create plugins that call the wizards
• distributor: the people that decide which wizard are installed in their distribution

Requirements

The requirements are in no particular order and numbered for easier reference:

0. All elements should have at leas one wizard
1. Load multiple wizard libraries
2. Users can switch between wizards
3. Technology independent
4. Wizards should have a single SCL element in focus
5. As few restriction as possible
6. Support different SCL Edition (e.g.: 2.0, 2.1)
7. Support support-files, like NSDocs, XSDs etc...
8. Plugin authors should be able to opt out and roll their own
9. Wizards has to be aware of the current locale

Details

0. All elements should have at least one wizard

This is more of an end-user requirement. If there are no wizards or there is a new element for which no wizard exists yet, we still want to provide something to enable the user to edit the element.

1. Load multiple wizard libraries

We want to allow distributors to install multiple wizards. This could be necessary when they want to support vendor specific elements that contains private fields. These won't be supported by the standard editors but by these specialized ones.

2. Users can switch between wizards

If we allow multiple wizards to one element, we also want to allow the end-user to switch between them. For example, vendor specific elements.

3. Technology independent

We do not want to limit the wizard authors in their choice of technology.

4. Wizards should have a single SCL element in focus

The main purpose of a wizard is to create or edit a specific SCL element. Other usages like utilizing it as simply way to display something in a dialog are not allowed

5. As few restriction as possible

We do not want to limit how wizard authors create or edit elements until that is the only thing they do (§4.)

6. Support different SCL Edition (e.g.: 2.0, 2.1)

It must be possible to know which SCL edition the current file has so wizards can decide how they should handle the element. An element is created maybe differently in edition 2.0 than in 2.1.

7. Support support-files, like NSDocs, XSDs etc...

Some elements may need supporting files. The wizards should get them and the wizard authors should not have to think too much about it.

8. Plugin authors should be able to opt out and roll their own

If a plugin author does not want to use the built-in wizarding, it is possible to roll your own easily and still maintain visual and functional unity.

9. Wizards has to be aware of the current locale

Wizards need the locale setting to display the current language

[danyill]

Perhaps this is obvious, but anyway:

Wizards should be able to be used by plugins independent of a distribution

For testing plugins and as part of the plugin architecture, it is important that a plugin with only open-scd-core can be used with wizards for testing.

[trusz]

Perhaps this is obvious, but anyway:

Wizards should be able to be used by plugins independent of a distribution

For testing plugins and as part of the plugin architecture, it is important that a plugin with only open-scd-core can be used with wizards for testing.

Do you mean that you don't want to include any wizards in the demo of your plugin?

[danyill]

Do you mean that you don't want to include any wizards in the demo of your plugin?

I mean I wish to be able to modularly include them in my plugin without a full distribution (i.e. works in core separately to OpenSCD).

[github-actions[bot]]

Hello there,

Thank you for opening this issue! We appreciate your interest in our project. However, it seems that this issue hasn't had any activity for a while. To ensure that our issue tracker remains organized and efficient, we occasionally review and address stale issues.

If you believe this issue is still relevant and requires attention, please provide any additional context, updates, or details that might help us understand the problem better. Feel free to continue the conversation here.

If the issue is no longer relevant, you can simply close it. If you're uncertain, you can always reopen it later.

Remember, our project thrives on community contributions, and your input matters. We're here to collaborate and improve. Thank you for being part of this journey!