Hinweis

  • 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

Don't Do

  • 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!

Beispiel

  • 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)
...
PY

Speichern in Wertebereichen

Don't Do

  • In Wertebereichen darf nicht gespeichert werden

Beispiel

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

Umlaute in Python-Skripten

Don't Do

  • 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

Regel

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

Hinweis

  • Relationen können zwischen Datentabellen und in Modulen definiert werden.

Zuordnen von Modulen zu Arbeitsgebieten

Regel

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

Hinweis

  • 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)

Regel

  • 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

Regel

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

Beispiel

  • Falsch:
...
try:
    ... # Quellcode, der einen Fehler verursacht
except:
    pass # Keinerlei Fehlerbehandlung
...
PY
  • Richtig:
...
try:
    ... # Quellcode, der einen Fehler verursacht
except ValueError as err: # Abfangen der Exception ValueError
    ... # Behandlung des Fehlers
...
PY

Hinweise

  • 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

Regel

  • 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

Regel

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

Inkarnationen

Regel

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

Startup-Module

Regel

  • 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

Regel

  • 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

Regel

  • 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

Information

Im Standard

  • 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 = ).
  • In Modulen wird nur die fachliche ID angezeigt (die technische ID steht in Fenster 9, meistens mit DF-Optionen = und Filterkriterium=).

In individuellen Customizings

  • 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=).

Customizing in Budgetbereichen

Information

  • 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.ä.)