Infopath: Bedenkenswertes
Interessant, wenn man überprüfen möchte, ob eine Software vielleicht das Richtige für einen ist, sind ja nicht nur die Features, die eine Anwendung mitbringt, sondern auch deren Grenzen.
Das Wissen um das, was alles nicht geht und was man besser nicht tun sollte, ist ein nicht zu unterschätzendes Wissen, das einem so manchen Ärger ersparen kann.
Infopath ist ein ziemlich “heißer” Kandidat, wenn es genau um diese Fragen geht. Die Chancen, mit etwas Internetrecherche zunächst darauf zu schließen, man habe es dann doch mit einer flexiblen, rundum leistungsfähigen Software zu tun, sind relativ hoch. Die Chancen, nach einiger Zeit trotzdem gegen eine Wand zu rennen, auch. Ja, ich würde sagen, Infopath verleitet geradezu, die Möglichkeiten zu überschätzen und sich Konstrukte zu überlegen, die langfristig nicht haltbar sind.
Einige bittere Erfahrungen in dieser Hinsicht habe ich selbst machen müssen, andere sind das Ergebnis einer wirklich eingehenden Analyse. Die nächste Sackgasse nämlich liegt gelegentlich erst ein paar Straßenblöcke weiter hinten.
Und so ergeben sich nach und nach einige Erkenntnisse, die recht wertvoll sind.
- Versuche nie, Infopath Vorlagen als Workaround für fehlende Sharepoint Features zu nutzen, auch wenn es reizvoll ist
- Nutze Infopath nicht, um die Logik relationaler Datenbank Beziehungen abzubilden, denn es überfrachtet XML
- Nutze Infopath ausschließlich, um einzelne, klein gehaltene (XML) Dokumente zu erstellen und zu speichern
- Vergiss trotz des graphischen Interfaces nie das XML und umgekehrt, denn beides hängt an einigen Stellen trügerisch zusammen
- Spezialisiere deine Infopath Vorlagen (beispielsweise Lieferschein, Rechnung etc.), beispielsweise auch in einzelnen Formularbilbiotheken
- Überlege vorab, welche Infopath XML Knoten als Spalten in die Sharepoint Formularbibliothek übernommen werden sollen, denn nicht jedes Konstrukt kann übernommen werden
- Belege wiederholte Abschnitte und Tabellen nur soweit wie unbedingt nötig mit Logik, denn es verlangt viel hinsichtlich des XPath und ist womöglich innerhalb der graphischen Oberfläche nicht realisiervar
- Sobald man sich eine globale Variable wünscht, ist es fast schon zu spät, da globale Variablen nur im Skript verfügbar sind
- Meide Workarounds, die zwar irgendwo zu finden, aber nicht offiziell dokumentiert sind. Infopath ist letztendlich nicht dafür gemacht
- Verlass dich nie ohne eingehende Analyse blind auf die erste Idee - aber das gilt nicht nur für Infopath
Grundsätzlich ist es wichtig, sich gerade in Kombination mit Sharepoint vorab zu überlegen, welche Formularbibliotheken benötigt werden, beispielsweise eine Bibliothek nur für Rechnungen oder eine nur für Bestellbestätigungen. Dies erleichtert zum einen, die richtige XML Struktur zu entwickeln als auch, Infopath Vorlagen mit integrierter externer Datenquelle klein zu halten.
Infopath: Simpel auf den ersten Blick. Wer die Anforderungen zu Beginn nicht komplett durchdenkt oder durchdenken kann, wiederholt Änderungen der XML Struktur gegenübersteht oder besondere Anforderungen an das interaktive Element hat, hat es mit einer komplexen Anwendung zu tun, die einen gelegentlich vor schier unlösbar anmutende Probleme stellt.
Infopath ist keine Software, die wirklich prädestiniert ist für Workarounds und Experimente. Auch wenn vieles möglich ist, so wird irgendwann doch klar, dass man unter Beachtung einiger Grundsätze und einem insgesamt anderen Ansatz besser gefahren wäre. Das kann gleich am Anfang ausgeschlossen werden. Und dann kann man eigentlich ganz glücklich werden mit Infopath.
