TXFAEventBinding
Unit: HPDFXFAEventScript
Deklaration
TXFAEventBinding= record
Name, ClassName: AnsiString;
ParentIndex: Integer;
Value, Presence, Access: AnsiString;
InstanceCount, InstanceGroup: Integer;
MinInstances, MaxInstances: Integer;
DefaultValue, DefaultPresence, DefaultAccess: AnsiString;
Repeated: Boolean;
Identity, ScriptSource, Locale, EventActivity: AnsiString;
Domain: TXFAEventBindingDomain;
DataIdentity: AnsiString;
DataBindingEnabled: Boolean;
Attributes, DefaultAttributes: TXFAEventAttributes;
PropertyPath: AnsiString;
PropertyOwnerIndex: Integer;
XML, DefaultXML: AnsiString;
DataBindingRef, DataContextIdentity: AnsiString;
DataBindingExplicit: Boolean;
end;
Verhalten
Beschreibt einen virtuellen Ereignis-Host-Knoten; jedes tatsächliche wiederholte Subformular-Vorkommen erhält ein eigenes Binding und eigene Kinder
ParentIndex wählt sein übergeordnetes Binding, oder -1 für die Wurzel; Value, Presence und Access beschreiben den aktuellen Vorkommenszustand
InstanceGroup identifiziert Bindings, die derselbe Instance Manager verwaltet, während InstanceCount und Vorkommensgrenzen die Manager-Grenzen beschreiben
Template-Defaults initialisieren neue Instanzen; Repeated identifiziert Knoten mit einer occur-Deklaration
TXFAWidgetRuntime baut diese Records aus dem Template und dem aktuellen Datasets-Kontext, bevor die Engine ausgeführt wird
Identity ist die stabile Host-Identität dieses Vorkommens; ScriptSource enthält JavaScript für ein Skriptobjekt, das innerhalb von variables deklariert ist
Eine leere Identity nutzt eine eindeutige Binding-Index-Identität; liefere stabile explizite Identitäten, wenn sich die Binding-Reihenfolge ändern kann, damit erhaltene Referenzen weiterhin dasselbe Vorkommen adressieren
Locale trägt das optionale locale-Attribut des Knotens als UTF-8-Text; der ausführende Knoten erbt den nächsten nichtleeren Vorfahrenwert, eine leere Kette wählt die User-Locale
EventActivity liefert xfa.event.name für das ausführende Binding; TXFAWidgetRuntime setzt Event-Activities sowie Calculate- oder Validate-Kontextnamen, während leere Bindings auf niedrigerer Ebene event verwenden
Domain unterscheidet Formularknoten von nativen datasets-, dataGroup- und dataValue-Knoten; der Default xebdForm erhält bestehende Aufrufer
DataIdentity referenziert die stabile Identität eines anderen Bindings, um ein Formularfeld oder Subformular mit seinem Datenknoten zu verbinden; Feld- und Datenwert-Lesezugriffe teilen sich dann einen Live-Wert
DataBindingEnabled erlaubt die implizite Datenknoten-Erzeugung, wenn ein wiederholter Formularprototyp keine bestehende Data-Bindung hat; Runtime-Felder mit bind match=none lassen es auf False und legen keinen synthetischen Datenknoten offen
Das Data-Domain-InstanceGroup zeichnet das gleichnamige Geschwister-Vorkommen für die native virtuelle Zielveröffentlichung auf; Data-Bindings legen keine Formular-Instance-Manager offen
Attributes enthält effektive aktuelle Property-Attribute; DefaultAttributes enthält Template-Attribute für einen neu geklonten Property-Knoten
Der Property-Domain-Name behält das tatsächliche name-Attribut, meist leer; sein ClassName liefert die SOM-Komponente, und seine Elternindizes bewahren Property-Hierarchie und lokale Geschwister-Vorkommen
PropertyPath und PropertyOwnerIndex identifizieren eine rein formularseitige Property, die im Template fehlt; der Pfad verwendet Klassen-Vorkommenskomponenten, und der Owner-Index wählt das native Formularvorkommen im selben Binding-Array
Runtime-Bindings nur für Formulare legen aktuelle native Attribute offen, während ihre DefaultAttributes Schema-Defaults nutzen; das Klonen eines wiederholten Prototyps erzeugt so Default-Property-Werte, statt den Override einer anderen Instanz zu erben
Lasse PropertyPath für bestehende Bindings deklarierter Properties leer; der zugehörige Owner-Index bleibt dann ungenutzt
Bei exData ist XML das aktuelle serialisierte UTF-8-Element, und DefaultXML liefert Template-Inhalte für eine neue wiederholte Instanz
Ein exData-Binding mit leerem XML startet von einem leeren nativen exData-Element; formularseitiges DefaultXML bleibt leer, damit ein neues Vorkommen nicht den importierten Fremdinhalt einer anderen Instanz erbt
XML-Eingabestrings zählen zum Byte-Budget des Ereigniskontexts; saveXML und loadXML nutzen validiertes Replay nativer Antworten und veröffentlichen über xeakLoadXML
Data-Domain-XML trägt die begrenzten flachen nativen XML-Metadaten der Runtime: Elementname, Namespace, Wert, Attribute, Namespace-Deklarationen, geordneten Nichttext-Inhalt und Kindpositionen; DefaultXML bleibt bei Datenknoten ungenutzt
Die Metadaten enthalten einen Knoten und seine direkten Text-, Kommentar- und Processing-Instruction-Kinder und vermeiden so einen duplizierten Nachfahren-Subbaum pro Data-Binding
DataBindingRef ist der getrimmte dataRef-Selektor; DataBindingExplicit unterscheidet eine explizit leere dataRef von einer impliziten Feldnamen-Bindung
DataContextIdentity identifiziert den tatsächlichen nativen Datenbereich des Felds unabhängig von DataIdentity, das sein ausgewähltes Blatt identifiziert
Diese Felder lassen XML-Importe Bindings sofort gegen das frische Data DOM neu bewerten, einschließlich neu verfügbarer Ziele sowie Nachfahren-, Wildcard-, Klassen- und Index-Auswahlen
Normale Anwendungen nutzen TXFAWidgetRuntime, um native Bindings zu bauen; Aufrufer auf niedrigerer Ebene können XML-Metadaten für rein skalare Datenknoten weglassen und die neuen Binding-Felder auf ihren Default-Werten lassen
Verwandte APIs
Interaktive Dynamic-XFA-Widget-Runtime, FormCalc-Funktionen und XFA Packet DOM