Tag für modifizierte Daten und modifizierte Eigenschaften

Jedes Feld in einem Textformular hat ein Tag für modifizierte Daten. Dabei handelt es sich um einen Statuswert, der angibt, ob der Benutzer das Formularfeld geändert hat, als das Formular zuletzt dargestellt wurde. Im Vergleich zu CICS ist ein Vorteil des geänderten Tags für modifizierte Daten, dass der Datenaustausch im Netz reduziert wird, weil die Datenübertragung vom Benutzer zum Programm nur die geänderten Felder einschließt.

Wie später beschrieben wird, unterscheidet sich ein Tag für modifizierte Daten von der Eigenschaft modified für das Feld, die im Programm festgelegt wird und den Wert des Tags für modifizierte Daten voreinstellt.

Mit dem Benutzer interagieren

In den meisten Fällen ist das Tag für modifizierte Daten auf NO voreingestellt, wenn das Programm das Formular dem Benutzer darstellt. Wenn der Benutzer dann die Daten in dem Formularfeld ändert, wird das Tag für modifizierte Daten auf YES gesetzt und Ihr Programm kann die folgende Logik verwenden:
  • Verwenden Sie eine Datentabelle oder Funktion, um die geänderten Daten auszuwerten (tritt automatisch auf, wenn das Tag für modifizierte Daten für das Feld YES lautet).
  • Erkennen Sie, dass der Benutzer das Feld geändert hat, indem Sie den Namen des Felds in eine Anweisung if einschließen, die die folgende Struktur aufweist:
      if (field is modified)
        ;
      end
    Details hierzu finden Sie unter Logische Ausdrücke für Text-UI-Formulare.

Der Benutzer legt das Tag für modifizierte Daten fest, indem er ein Zeichen in das Feld eingibt oder daraus löscht. Das Tag für modifizierte Daten bleibt unverändert, selbst wenn der Benutzer, bevor er das Formular übergibt, den Feldinhalt an den Wert zurückgibt, der dargestellt wurde.

Die Auswertung umfasst zwei Phasen. Phase I bezieht Eigenschaften wie InputRequired ein, ebenso wie Auswertungen von Datentabellen. In Phase II werden Validator-Funktionen ausgeführt. Wenn ein Formular aufgrund eines Fehlers in Phase I erneut angezeigt wird, ist das Tag für modifizierte Daten in jedem Feld, das geändert wurde, nachdem das Programm converse oder show ausgeführt hat, immer noch auf YES festgelegt. Wenn jedoch ein Formular aufgrund eines Fehlers in Phase II erneut angezeigt wird, ist das Tag für modifizierte Daten in keinem Feld mehr aktiv, es sei denn, eine Validator-Funktion setzt das Tag zurück.

Eigenschaft 'modified' festlegen

Sie möchten unter Umständen, dass Ihr Programm eine Task ausführt, unabhängig davon, ob der Benutzer ein bestimmtes Feld geändert hat oder nicht. Beispiel:
  • Möglicherweise möchten Sie die Auswertung eines Kennwortfelds erzwingen, selbst wenn der Benutzer keine Daten in dieses Feld eingegeben hat.
  • Sie können eine Validator-Funktion für ein kritisches Feld angeben (selbst für ein geschütztes Feld), sodass das Programm immer eine bestimmte feldübergreifende Auswertung durchführt, was bedeutet, dass Ihre Programmlogik eine Gruppe von Feldern auswertet und in Betracht zieht, wie sich der Wert eines Felds auf die Gültigkeit eines anderen auswirkt.
Zur Abwicklung früherer Fälle können Sie die Eigenschaft modified für ein bestimmtes Feld entweder in Ihrer Programmlogik oder in der Formulardeklaration festlegen:
  • Schließen Sie eine Anweisung set field modified in die Logik ein, die der Darstellung des Formulars vorangeht. Das Ergebnis ist, dass das Tag für modifizierte Daten für das Feld bei Darstellung des Formulars auf YES voreingestellt wird.
  • Legen Sie in der Formulardeklaration die Eigenschaft modified des Felds auf YES fest. In diesem Feld gelten die folgenden Regeln:
    • Wenn das Formular zum ersten Mal dargestellt wird, ist das Tag für modifizierte Daten auf YES voreingestellt.
    • Wenn eine der folgenden Situationen auftritt, bevor das Formular dargestellt wird, ist das Tag für modifizierte Daten auf YES voreingestellt, wenn das Formular dargestellt wird:
      • Der Code führt eine Anweisung set field initial aus, die den Originalinhalt und die Eigenschaftswerte für das Feld erneut zuordnet. ODER
      • Der Code führt eine Anweisung set field initialAttributes aus, die die ursprünglichen Eigenschaftswerte (aber nicht den Inhalt) für jedes Feld im Formular erneut zuordnet. ODER
      • Der Code führt eine Anweisung set form initial aus, die den Originalinhalt und die Eigenschaftswerte für jedes Feld in dem Formular erneut zuordnet. ODER
      • Der Code führt eine Anweisung set form initialAttributes aus, die die ursprünglichen Eigenschaftswerte (aber nicht den Inhalt) für jedes Feld im Formular erneut zuordnet.
Die set-Anweisungen wirken sich auf den Wert der Eigenschaft modified aus, nicht auf die aktuelle Einstellung des Tags für modifizierte Daten. Ein Test des folgenden Typs basiert auf dem Wert des Tags für modifizierte Daten, das gültig war, als die Formulardaten das letzte Mal an Ihr Programm zurückgegeben wurden:
  if (field is modified)
    ;
  end
Wenn Sie versuchen, das Tag für modifizierte Daten für ein Feld zu testen, bevor Ihre Logik das Formular zum ersten Mal darstellt, tritt ein Laufzeitfehler auf.
Wenn Sie ermitteln müssen, ob der Benutzer (und nicht das Programm) ein Feld geändert hat, stellen Sie sicher, dass der Wert des Tags für modifizierte Daten für das Feld auf NO voreingestellt ist:
  • Wenn die Eigenschaft modified des Felds in der Formulardeklaration auf NO festgelegt ist, verwenden Sie keine Anweisung set field modified. In Abwesenheit dieser Anweisung wird die Eigenschaft modified vor jeder Formularpräsentation automatisch auf NO festgelegt.
  • Wenn die Eigenschaft modified des Felds in der Formulardeklaration auf YES festgelegt ist, verwenden Sie eine Anweisung set field normal in der Logik, die jeder Formularpräsentation vorangeht. Diese Anweisung legt die Eigenschaft modified auf NO fest und stellt das Feld (in einem zweiten Ergebnis) als ungeschützt dar, mit einer normalen Intensität.

Formular auf Änderungen testen

Das gesamte Formular wird als geändert betrachtet, wenn das Tag für modifizierte Daten für eines der variablen Formularfelder auf YES gesetzt ist. Wenn Sie den geänderten Status eines Formulars testen, das dem Benutzer noch nicht präsentiert wurde, lautet das Testergebnis FALSE.

Beispiele

Setzen wir die folgenden Einstellungen im Formular form01 voraus:
  • Die Eigenschaft modified ist für das Feld field01 auf NO gesetzt.
  • Die Eigenschaft modified ist für das Feld field02 auf YES gesetzt.

Die folgende Logik zeigt das Ergebnis der verschiedenen Tests an:

  // tests false because a converse statement 
  // was not run for the form
  if (form01 is modified)
    ;
  end

  // causes a runtime error because a converse 
  // statement was not run for the form
  if (field01 is modified)
    ;
  end

  // assume that the user modifies both fields
  converse form01;

  // tests true
  if (field01 is modified)
    ;
  end

  // tests true
  if (field02 is modified)
    ;
  end

  // sets the modified property to no 
  // at the next converse statement for the form 
  set field01 initialAttributes;
  
  // sets the modified property to yes 
  // at the next converse statement for the form 
  set field02 initialAttributes;

  // tests true 
  // (the previous set statement takes effect only
  // at the next converse statement for the form
  if (field01 is modified)
    ;
  end

  // assume that the user does not modify either field
  converse form01;

  // tests false because the program set the modified 
  // data tag to no, and the user entered no data 
  if (field01 is modified)
    ;
  end

  // tests true because the program set the modified 
  // data tag to yes
  if (field02 is modified)
    ;
  end
  
  // assume that the user does not modify either field
  converse form01;

  // tests false
  if (field01 is modified)
    ;
  end

  // tests false because the presentation was not
  // the first, and the program did not reset the
  // field properties to their initial values
  if (field02 is modified)
    ;
  end


Feedback