Customizing-Regeln

• Dieses Topic beinhaltet
  • Don't Dos: Diese dürfen beim Customizing in PLANTA project nicht verwendet werden, da sie zu (schweren) Fehlern bis hin zu Programmabstürzen führen können.
  • Regeln: Diese sollten beim Customizing in PLANTA project beachtet werden.

Don't Dos

Zugreifen auf Objekte

• Auf Objekte, die anwendungsseitig ihren Lebenszyklus beendet haben (z.B. ein Modul, das geschlossen wird), darf in keiner Weise mehr über Python zugegriffen werden. Jeder Methoden/Attributs-Aufruf an ein geschlossenes Modul/Panel kann zu Programminstabilitäten und -abstürzen führen!

• Der folgende Code führt zu einem Absturz, weil ein Modul-Objekt erst geschlossen wird und dann versucht wird, in diesem zu speichern:

...
mod.menu(49)
mod.menu(34)
...

Speichern in Wertebereichen

• In Wertebereichen darf nicht gespeichert werden

...
def computeOutput(di): 
    ...
    ppms.get_active_module().menu(34) 
    ...
 
computeOutput.deps = (...)
...

Umlaute in Python-Skripten

• In Python-Skripten (Wertebereiche, Makros, Python-Module auf dem Server und Modul-Unterklassen) dürfen keine Umlaute (ä, ü, ö) verwendet werden. Dies gilt auch für auskommentiere Code-Zeilen oder Kommentare.

Regeln

Customizen von Relationen

• Relationen werden nur unterstützt, wenn sie dem gleichen Datentyp entsprechen.

• Relationen können zwischen Datentabellen und in Modulen definiert werden.
  • Relation zwischen Datentabellen werden in der Relation angelegt.
  • In Modulen können Relationen in den Parametern Relation zu Oberbereich und Rekursive Relation definiert werden.

Zuordnen von Modulen zu Arbeitsgebieten

• Jedes Modul, das verwendet wird, muss einem Arbeitsgebiet zugeordnet werden.

• Solange das Modul-Customizing noch nicht abgeschlossen ist, kann dieses Modul einem entsprechenden Arbeitsgebiet im Modul Indirekte Module zugeordnet werden.

Globale Einstellungen (Austauschbarkeit von Objekten)

• In den globalen Einstellungen müssen alle in Makros verwendeten Objekte hinterlegt werden, z.B.
  • Module
  • Modulvarianten
  • Dialogmeldungen
  • OLEs
• Dies gewährleistet eine einfache Austauschbarkeit von Objekten, z.B. Modulen, ohne alle Python-Skripte durchsuchen zu müssen.

Try/Except in Python-Code

• In Python-Code darf Try/Except nur verwendet werden, wenn
  • die Verwendung in einem Kommentar begründet wird oder
  • ein bestimmter Fehlertyp abgefangen wird

• Falsch:

...
try:
    ... # Quellcode, der einen Fehler verursacht
except:
    pass # Keinerlei Fehlerbehandlung
...

• Richtig:

...
try:
    ... # Quellcode, der einen Fehler verursacht
except ValueError as err: # Abfangen der Exception ValueError
    ... # Behandlung des Fehlers
...

• Wird kein Fehlertyp angegeben, wird jeder Fehler abgefangen. Dies kann zu unerwünschtem Verhalten führen.
• Weitere Informationen zum Verwenden von Try/Except finden Sie hier...

Neustarten des Servers

• Im Falle von Änderungen am Data-Dictionary (DT412) muss der Server aufgrund des Preloadings neu gestartet werden.
  • Dazu wird vom System die Python-Funktion restart_server() bereitgestellt.
  • Der Administrator kann unter Linux den Server mit "/etc/init.d/planta reload" neustarten.

Session-Neustart nach Customizingänderungen

• Symbole, Farben und Formate werden gecacht, daher muss nach Änderungen an diesen die Session neugestartet werden.

Inkarnationen

• Für jede Inkarnation, die nicht output ist, muss
  • eine Listbox zugeordnet werden und
  • die Checkbox Listboxzwang aktiviert werden.

Startup-Module

• Jedes Startup-Modul, das ein anderes Modul startet, muss vor dem Aufruf des Moduls prüfen, ob dieses bereits geöffnet ist,
  • wenn ja, soll das bereits geöffnete Modul fokussiert werden.
  • wenn nein, soll das Modul gestartet werden.

Python-IDs

• Jedes DataItem muss eine gültige Python-ID besitzen.
• Python-IDs von Standard-DIs, -Datenbereichen, -Datenfeldern und in den globalen Einstellungen dürfen nicht geändert werden.
• Python-IDs von individuellen Dataitems in Standard-Datentabellen müssen mit L und der Lizenznummer anfangen, z.B. L111_stakeholder
• In individuellen Datentabellen kann die Lizenznummer weggelassen werden
  • Vorteil: Wird für ein DI, das die Projekt-ID beinhaltet, die Python-ID pr_id hinterlegt, kann ein Standardmakro verwendet werden um ein Projekt aufzurufen.

DI-Bezeichnungen

• Sinnvolle DI-Bezeichnungen verwenden - z.B. ein Feld nicht "Apa:Name+Vorname" nennen, sondern nur "Name". Die "technischen Informationen" können im Notizfeld hinterlegt werden.

Customizen mit fachlicher und technischer Projekt-ID

• In PLANTA project wird zwischen der fachlichen Projekt-ID und der technischen Projekt-ID unterschieden.

• Die @L-Variablen werden immer auf die technische ID gesetzt, da
  • nur auf diesen Dataitems ein Index liegt, der die Suche beschleunigt.
  • Module mit dieser Vorbelegung in der Regel in Workflows eingebunden sind, in denen die Folgemodule auch damit arbeiten (nicht nur als Filter, sondern auch in den Pythonmakros für den Zugriff auf die Datenbank).
• In Modulen, die standardmäßig einen Filter mit @L auf Hauptprojekt bzw. Projekt haben, haben die Anwender keine Möglichkeit, die Filterkriterien auf Projektebene zu ändern (alle Projektfelder erhalten in den Datenfeldern Filterkriterium =
  Error rendering macro 'fontawesome-macro' : Page loading failed
  ).
• In Modulen wird nur die fachliche ID angezeigt (die technische ID steht in Fenster 9, meistens mit DF-Optionen =
  Error rendering macro 'fontawesome-macro' : Page loading failed
  und Filterkriterium=
  Error rendering macro 'fontawesome-macro' : Page loading failed
  ).

• Soweit es geht, soll diese Logik ebenfalls beachtet werden.
• Für Ausnahmefälle bestehen zwei Möglichkeiten:
  • Der Customizer bietet beide IDs in der Auswahl an und ändert die Datenfeldbezeichnung so, dass es für die Anwender verständlich wird.
  • Der Customizer bietet nur die vorbelegte technische ID an und zusätzlich z.B. die Projektbezeichnung.
  • In beiden Fällen müssen die Anwender darauf hingewiesen werden, dass Sie ihr eigenes Kriterium eingeben und die Vorbelegung (@L) entfernen müssen.
• Bei den meisten individuellen Modulen (insbes. Reports) ist es nicht erforderlich eine Vorbelegung auf die Projektnummer zu machen. In diesen Fällen sollte immer nur die fachliche ID anzeigt werden und als Filter zugelassen werden (die technische ID steht in Fenster 9 und das Filterkriterium=
  Error rendering macro 'fontawesome-macro' : Page loading failed
  ).

Customizing in Budgetbereichen

• Das Design von Kosten- und Budgetbereichen muss sich immer an dem des Moduls Budget orientieren. Dies beinhaltet:
  • Gruppierungs-Überschriften wie "Kosten" und "Aufwand" sind fett
  • Der Bereich "Nutzen+Erlöse" befindet sich unterhalb der Aufwände
  • Es wird das Default-Schrift Symbol verwendet (keine ausgegrauten Bereiche o.ä.)