Da wir künftig nur eine Modul-Code-Basis für Standard Clients, MFE, WFC und WebClient nutzen werden, sollte die XML-Event-Schnittstelle implementiert werden -- ohne dynamic bzw jscript (die Lösung dafür, muss gesondert angegangen werden). Die Nutzung der Helper-Klassen sollte, soweit es geht, gemieden werden, weil dadurch die Portabilität unserer Module nicht mehr gewährleistet ist. Wenn es nicht anders geht, sollten die Helper dann (wie bisher) in Form von eigenständigen Modulen bereitgestellt werden.
Die XML-Event-API ist hier definiert. Sicherlich sollte es in mehreren Milestones, nach Wichtigkeit, realisiert werden, z.B.
Events.ML1: SQL
Felder ohne SQL-Index zulassen. Es handelt sich um offline-Felder, die durch die Event-API mit Werten belegt werden
Button und MessageBox-Unterstützung
Prozedur-Aufruf Unterstützung
Events.ML2: Dienst-Kommunikation
Vermutlich durch einen Aufruf des Backends nutzbar, z.b. server/send/?service=jobexecutor o.ä.
Da wir (vorerst) keine persistenten Verbindungen wollen, soll die event-Versand-Anfrage vom Backend mit einem Communication-Key beantwortet werden, der wiederum dazu genutzt werden kann die Antworten des Dienstes zu pollen
Da wir künftig nur eine Modul-Code-Basis für Standard Clients, MFE, WFC und WebClient nutzen werden, sollte die XML-Event-Schnittstelle implementiert werden -- ohne dynamic bzw jscript (die Lösung dafür, muss gesondert angegangen werden). Die Nutzung der Helper-Klassen sollte, soweit es geht, gemieden werden, weil dadurch die Portabilität unserer Module nicht mehr gewährleistet ist. Wenn es nicht anders geht, sollten die Helper dann (wie bisher) in Form von eigenständigen Modulen bereitgestellt werden.
Die XML-Event-API ist hier definiert. Sicherlich sollte es in mehreren Milestones, nach Wichtigkeit, realisiert werden, z.B.
Events.ML1: SQL
Events.ML2: Dienst-Kommunikation
Events.ML3: TBD
Siehe auch https://github.com/minova-afis/aero.minova.rcp/issues/1593