Designrichtlinien (Reporting)

Dieser Artikel listet Vorschläge auf, die für übersichtliche, wartbare und möglichst fehlerfreie sorgen sollen.

Die neue Basisreportsammlung wurde entsprechend dieser Leitlinien entwickelt.

1. Nutzen Sie wenn möglich existierende Reports der Basisreportsammlung. Erzeugen Sie also nach Möglichkeit keine speziellen "Einzelfallreports" wie eine "Kakaoliste". Nutzen Sie lieber einen universell verwendbaren Report aus der Basisreportsammlung.
2. Nutzen Sie wenn möglich die Serienbriefe, für die Sie eigene Texte anlegen und speichern können, die bei Bedarf in die Serienbriefreports geladen werden.
3. Wenn Sie einen eigenen Report erstellen, passen Sie wenn möglich einen der Reports aus der Basisreportsammlung an und übernehmen Sie so viel vom Layout wie möglich.

Layout

• Achten Sie auf ein einheitliches Layout von neuen Reports. Basieren Sie Ihre Reports wenn möglich auf der Basisreportsammlung.
• Das Layout muss robust gegenüber erwartet und unerwartet langen Einträgen sein. Ein Beispiel wäre, dass lange Namen abgeschnitten werden oder dass Felder in andere hineinreichen. Planen Sie hier so, dass es möglichst keine Kollisionen gibt. Falls sich mögliche Kollisionen nicht verhindern lassen, planen Sie so, dass das Feld in der Größe beschränkt ist und der abgeschnittene Teil unproblematisch ist. Im "offiziellen" Bereich, d.h., Briefe die etwa an Erziehungsberechtigte gehen, kann überlegt werden, die Schriftgröße so anzupassen, dass das Feld a
• Um Felder in der Höhe wachsen zu lassen, verwenden Sie Memofelder, hier wird auch der Detailbereich dynamisch angepasst. Oft lässt sich der zu erwartende Inhalt mit einer statischen Höhe gut abbilden.
• Verwenden Sie keine dynamisch eingebundenen Subreports. Wird dieser in irgendeiner Weise verändert, kann im eigentlichen Report alles verschoben werden, Schriftarten passen nicht mehr und so weiter.
• Verwenden Sie nur eine Schriftart. Richten Sie sich nach den hauptsächlich verwendeten Schriftarten (derzeit ist "Calibri" die Standardschriftart in MS Windows).
• Nutzen Sie keinen Code, um etwa alternierende Hintergründe zu erzeugen. Verwenden Sie hierzu die Funktion des Detailbereichs, so der etwas automatisch vornimmt.
  • Entsprechend nutzen Sie auch keine "Formen" um gefärbte Hintergründe zu erzeugen, wenn sich dies durch die Färbung des Detailbereichs herbeiführen lässt - zum Beispiel bei der Verwendung von Subreports in Leistungsübersichten.
  • Ebenso kann der Detailbereich genutzt werden, um Rahmen zu erzeugen. Nutzen Sie hier bitte keine Formen oder Linien. Eine Ausnahme kann die Verwendung von senkrechten Linien mit Höhe der Stammkomponente gesetzt sein.
• Legen Sie den Dateinamen des Reports über eine Systemvariable im Fuß ab.
• Erzeugen Sie Ihren Report in den Größen als "What you see is what you get" - wenn Sie also einen A4-Brief erzeugen, lassen Sie auch die Vorlage im Report-Designer nach A4 aussehen.
• Enthält der Report viele Informationen, arbeiten 2- oder auch 3-spaltig, als Beispiele wären hier die aktuellen Stammblätter zu nennen.

Technik

• Laden Sie keine Header und Footer nach, der Report soll alleine für sich stehen.
• Vermeiden Sie wenn möglich Subreports.
• Verwenden Sie die Pipeline "Klassen" nicht. Um nach Klassen oder anderen Kriterien zu trennen, nutzen Sie die Pipeline "Schüler" und führen die Trennung über Gruppen durch.
• Filtern Sie nach Möglichkeit Schüler nicht innerhalb eines Reports. Die Filterung soll immer durch den Nutzer durch die Auswahl der Schüler im Schülercontainer vorgenommen werden.
• Wenn in komplexeren Reports Tabellen verwendet werden, nutzen Sie einen Subreport, dessen Ausdehnung des Detailbereichs den Rahmen festlegt. Grids werden hier in der Regel nicht benötigt.
• Für Listen von Personengruppen, etwa Schüler, testen Sie, ob 34 Einträge möglich sind. Testen Sie auch mit einer Person mit langen Feldinhalten (je nach Anwendungsfall etwa Name, Straße, ...)
• Alle Objekte wie Labels oder DBFelder sollten auch passend umbenannt werden. Bennen Sie also "DBText1" besser in "DBVorname". Das gleiche gilt auch für Labels und so weiter.
• Richten Sie Objekte wie Labels präzise aus, indem Sie die Position und Width usw. direkt per Zahleneingabe händisch auf ganze Zahlen oder genaue Nachkommastellen setzen.

Code

• Vermeiden Sie Code, wo immer dies möglich ist. Sollte der Reportdesigner eine Möglichkeit anbieten, etwas mit den Tools und Feldern anzuzeigen, nutzen Sie diese Option.
  • Nutzen Sie wo möglich Memofelder mit MailMerge, um DB-Daten zu verarbeiten.
  • Wenn Code verwendet werden muss, setzen Sie ihn so sparsam wie möglich ein.
  • Erzeugen Sie Code an möglichst weinigen Stellen. Verteilen Sie bitte keinen Code über alle möglichen Objekte, die über einen ganzen Report und Subreports verteilt sind.
• Soll in Reports eingegriffen werden, verwenden Sie Paramenters als definierbare und mit vor eingestellten Werten geladene Variablen. Der Parameter lässt sich im Report ändern, indem der Parameter geändert und der Report gespeichert wird. Drücken Sie nach der Eingabe Enter, um den Parameter zu speichern.
• Hinweis bei Zählern: Das Event "Detail Before Print" kann in Grenzfällen Schüler doppelt zählen. Verwenden Sie "Detail After Print".
• Variablen müssen sprechend und eindeutig benannt sein.
• Schreiben Sie Code so sprechend, dass Kommentare nicht notwendig sind.
• Setzen Sie Kommentare, wo diese notwendig sind.
• Überlegen Sie beim Code auch unbedingt, welche Randbedingungen und Spezialfälle bei den verarbeiteten Feldern auftreten können, um diese direkt sinnvoll zu behandeln. Zum Beispiel ist zu beachten, dass SchILD-NRW vier mögliche Einträge beim Feld Geschlecht kennt und die Verarbeitung von m/w nicht ausreicht oder dass in Notenfeldern mitunter anderen Werte wie NB stehen können. Achten Sie auch auf mögliche Leereinträge.