Questions & Answers

[boesebeck]

Hallo,

Habt ihr schonmal Module entwickelt? Wenn ja - was für welche, was haben diese gemacht? Wobei habt ihr Probleme gehabt?

Gerrit

[aVogt]

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.

• Mails versenden,
• Medien umbenennen und in andere Ordner verschieben (wegen Zugriffsrechten auf dem Webserver),
• Ermittlung von Informationen von Datensätzen wenn ich nur eine ID und die Tabelle habe.
• Methoden für den Import von externen Daten (in Medienordner und Datequellen - hier hab ich ein Script aus einem Projekt - das hat e-Spirit erstellt - erweitert und als Klasse gebaut)

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

[king]

Ja, haben wir, in diesem Fall sogar etwas "spektakuläreres": Anbindung von Drittsystemen über Web-Service-Clients. Die Schwierigkeiten hierbei:

• die ClassLoader-Hierarchie anhand der Dokumentation zu verstehen (ModuleDeveloper-Handbook: das müsste besser formuliert werden)
  
• 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)
  

[nikb]

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.

[boesebeck]

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?

[boesebeck]

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.

[Peter_Jodeleit]

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".