Allow for configuring the default values of properties. Provide a machine readable file that includes all default values of properties for each widget

Offen
  • Stimmt etwas nicht?
#3,815 5 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
5/5
Geschätzter Aufwand
Über eine Woche
Anfängerfreundlichkeit
35/100
Issue-Typ
Feature
Klarheit
Größtenteils klar
Aktivitätsstatus
Ruhig
Tech-Stack
java
Bereich
tooling

Rechercherichtung

Start by locating where Phoebus widgets define their property defaults and how those definitions are exposed to clients. Compare the proposed machine-readable file with the alternative of generated documentation, then identify how either approach can cover every widget and property. Done means clients can reliably determine omitted property values, with the result kept in sync when defaults change.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

It is legal in phoebus to have a bob file that defines a widget that omits most of the property tags. Any omitted tags will have some default value, which of course will not be available to a client that reads just the xml.

This is problematic for cases where we'd like to do things like check the state of a set of screens against some condition. Unless we happen to know what the default value of a particular property is for a particular widget, we cannot perform the check if the xml does not include the information.

Of course, I could open the editor, drag a widget, and see what the initial value is, but this is a brittle solution that is subject to breaking if the defaults ever change. It would be good if the default values for all properties for all widgets were in a machine readble (i.e. json or yaml) file with a defined schema somewhere that clients could read for a base state. Alternatively, it would be good if at least there were a automatically updated document that listed all of these default values in the documentation.

For context, I am developing a linter for phoebus screens: https://github.com/NSLS2/phoebuslint. It works pretty well but I am running into things like this:

Have a rule that checks if a widget is outside of the bounds of a screen. The screen is configured to be 400 x 600, but since 600 is the default width it is omitted in the xml. The linter doesn't know about this and defaults to 0, so every widget gets marked as out of bounds.

For now, I've hard coded the default value, but it would be great if we could put together a more robust solution.

Vorherrschende Sprache
Java
Sterne
130
Forks
132
Ø Merge
2 T. 7 Std.
Gemergte PRs (30 T.)
26

Entwicklungsumgebung

  • Kein Dockerfile und keine Docker-Compose-Datei
  • Hat eine Pull-Request-Vorlage
  • Kein Beitragsleitfaden

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus ControlSystemStudio/phoebus

Alle Issues in ControlSystemStudio/phoebus

Ähnliche Issues

Weitere Issues zu Java

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.