IF ... THEN ... ELSE mit XML

Ich persönlich denke, dass das if / then / else irgendwie verknüpft werden muss.

Vielleicht eine andere Möglichkeit, bedingte Konstrukte in XML zu codieren:

Angesichts eines ähnlichen Problems vor einiger Zeit entschied ich mich für eine verallgemeinerte Lösung "switch ... case ... break ... default" zusammen mit einem arm-style Befehlssatz mit bedingter Ausführung. Ein benutzerdefinierter Interpreter, der einen Schachtelungsstapel verwendet, wurde verwendet, um diese "Programme" zu parsen. Diese Lösung vermeidet vollständig IDs oder Labels. Alle meine XML-Sprachelemente oder "Anweisungen" unterstützen ein "Bedingungs" -Attribut, das, wenn es nicht vorhanden ist oder wenn es als wahr ausgewertet wird, dann die Anweisung des Elements ausgeführt wird. Wenn ein "Exit" -Attribut als wahr ausgewertet wird und die Bedingung auch wahr ist, dann wird die folgende Gruppe von Elementen / Instruktionen auf der gleichen Verschachtelungsebene weder ausgewertet noch ausgeführt und die Ausführung wird mit dem nächsten Element / Instruktion bei der nächsten fortgesetzt Elternebene. Wenn es kein "Exit" gibt oder es zu false ausgewertet wird, fährt das Programm mit dem nächsten Element / Befehl fort. Zum Beispiel können Sie diese Art von Programm schreiben (es wird nützlich sein, eine noop "Anweisung" zu geben und ein Mechanismus / Anweisung, um Werte und / oder Ausdrücke zu "Variablen" zuzuweisen, wird sich als sehr nützlich erweisen):

Wenn ausdruck-a wahr ist, lautet die Ausführungssequenz:

Wenn Ausdruck-a falsch ist und Ausdruck-b wahr ist, dann wird es sein:

Wenn sowohl ausdruck-a als auch ausdruck-b falsch sind, dann haben wir:

PS. Ich habe "exit" anstelle von "break" verwendet, weil ich "break" verwendet habe, um "Breakpoints" zu implementieren. Solche Programme sind sehr schwer zu debuggen ohne eine Art Breakpointing / Tracing-Mechanismus.

PS2. Weil ich ähnliche Datum-Zeit-Bedingungen wie Ihr Beispiel und die anderen Bedingungen hatte, habe ich auch zwei spezielle Attribute implementiert: "von" und "bis", die auch, falls vorhanden, wie "Bedingung" ausgewertet werden mussten, und die spezielle schnelle Datum-Zeit-Prüflogik verwendet.

Scheint mir leichter zu lesen. Es gibt mehr Verschachtelungen, aber was hilft bei der Lesbarkeit?

Ich glaube nicht, dass Sie das Konstrukt "Wenn-dann-sonst" entwerfen können, ohne das Design für andere Konstrukte zu berücksichtigen. Ich denke, es ist ein guter Grundsatz, dass jeder Ausdruck ein Element sein sollte, und seine Unterausdrücke sollten Kindelemente sein. Es gibt dann Fragen darüber, ob der Name eines Elements den Typ des Ausdrucks oder seine Rolle relativ zum Eltern widerspiegelt. Oder Sie können beides tun:

Aber Sie können manchmal mit einem Design davonkommen, das die Rollennamen (condition, then else) weglässt und sich auf die positionale Bedeutung von Elementen relativ zu ihrem Elternteil verlässt. Es hängt ein bisschen davon ab, wie viel Sie es kurz halten wollen.

Ich denke, dass Sie daran denken müssen, dass Ihre XML-Datei von einer Maschine verarbeitet wird und nicht von einem Menschen, so dass sie nur für die Maschine lesbar ist.

Mit anderen Worten, ich denke, Sie sollten das XML-Schema verwenden, das Sie benötigen, um die Regeln zur Laufzeit so effizient wie möglich zu analysieren.

Soweit Ihr aktuelles Schema geht, denke ich, dass das Attribut id für jedes Element eindeutig sein sollte. Vielleicht sollten Sie ein anderes Attribut verwenden, um die Beziehung zwischen IF , THEN und% co_de zu erfassen % Elemente.

Ich weiß nicht, ob das für irgendjemanden Sinn macht oder es tatsächlich in Ihrem Programm verwendbar ist, aber ich würde es so machen.

Mein Standpunkt: Sie müssen alles mit Ihrem "IF" in Ihrem IF-Tag haben, sonst wissen Sie nicht, was ELSE zu welchem ​​IF gehört. Zweitens würde ich das THEN-Tag überspringen, weil es immer einem IF folgt.

Persönlich würde ich

Auf diese Weise brauchen Sie kein Attribut id , um die Tags IF , THEN , ELSE

Hier ist meine Meinung dazu. Dadurch können Sie mehrere Bedingungen haben.