Search the FirstSpirit Knowledge Base
Hallo,
Habt ihr schonmal Module entwickelt? Wenn ja - was für welche, was haben diese gemacht? Wobei habt ihr Probleme gehabt?
Gerrit
Jepp haben wir, allerdings nicht allzu spektakuläres.
Ich habe da nur Methoden zusammengefasst, die immer wieder in einem Script (das in einem Workflow auf Datenquellen verwendet wird) gebraucht werden,
z.B.
Solche Sachen halt
Probleme hatte ich eigentlich keine. Ist auch besser so ein Modul, da man da gezwungen wird ordentlich zu programmieren, was man in den Scripten nicht musss.
Grüße Andreas
Ja, haben wir, in diesem Fall sogar etwas "spektakuläreres": Anbindung von Drittsystemen über Web-Service-Clients. Die Schwierigkeiten hierbei:
Ja, ein FSM Formularmodul welches serverseitige Validierung unterstützt. Die Validierungsregeln und Fehlermeldungen lassen sich vom Redakteur einstellen. Es können verschiedene E-Mail Templates in einer Datenquelle gepflegt und ausgewählt werden. Formularfelder werden richtig serialisiert und in einer Datenbank geloggt.
Als FSM ist es in FirstSpirit integriert und funktioniert sehr gut.
Die Dokumentation ist uns bei der Entwicklung unvollständig erschienen. Im ModulDeveloperDoc.pdf fehlen konkretere Hinweise für die Entwicklung von Web-Anwendungen (z.B.: Hinweis über zu erweiternde Klassen in Kapitel 2.9.1.5. ist widersprüchlich zu Hinweis in Kapitel 3.1; Wie sieht eine typische module.xml für Webanwendungen aus? Eine Beispielanwendung wäre ebenfalls schön gewesen).
In der API Dokumentation wäre es gut zusätzlich Informationen über die konkreten Implementierungsklassen der Interfaces und die Klassenzusammenhänge zu bekommen.
Holger King schrieb:
- die individuelle Anpassung des Konfigurationsdialogs (bis dato war bspw. keine Validierung der Eingaben bei Klick auf den OK-Knopf möglich! -> das FirstSpirit-Modul-Framework erlaubt dies nicht)
Können Sie hierzu ein Feature Request anlegen?
Niklas Bulitta schrieb:
Die Dokumentation ist uns bei der Entwicklung unvollständig erschienen. Im ModulDeveloperDoc.pdf fehlen konkretere Hinweise für die Entwicklung von Web-Anwendungen (z.B.: Hinweis über zu erweiternde Klassen in Kapitel 2.9.1.5. ist widersprüchlich zu Hinweis in Kapitel 3.1; Wie sieht eine typische module.xml für Webanwendungen aus? Eine Beispielanwendung wäre ebenfalls schön gewesen).
In der API Dokumentation wäre es gut zusätzlich Informationen über die konkreten Implementierungsklassen der Interfaces und die Klassenzusammenhänge zu bekommen.
Wir werden die Punkte in einer zukünftigen Version berücksichtigen. Der Bereich der Webanwendungen in der Moduldokumentaion wird aktuell erweitert, es wird dann auch eine Beispiel WebApp existieren.
Klarstellung zu der Antwort von Gerrit
Niklas Bulitta schrieb:
In der API Dokumentation wäre es gut zusätzlich Informationen über die konkreten Implementierungsklassen der Interfaces [..] zu bekommen.
Zu Implementierungsklassen wird es keine Informationen gegeben, die Interfaces sind ja gerade dafür da, Stabilität zu gewährleisten. Für Implementierunge könnten wir das nicht garantieren, daher bieten wir die Interfaces an.
Im Gegenteil: Die Benutzung von Methode, Feldern, Konstruktoren etc. die nicht dokumentiert sind, sollte unbedingt vermieden werden, da diese sich jederzeit ändern können - und zwar "without further notice".