Customizing-Regeln

warning 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

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

application 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)
...

Speichern in Wertebereichen

stop Don't Do
  • In Wertebereichen darf nicht gespeichert werden

application Beispiel

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

Umlaute in Python-Skripten

stop 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

note Regel

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

warning Hinweis

Zuordnen von Modulen zu Arbeitsgebieten

note Regel
  • Jedes Modul, das verwendet wird, muss einem Arbeitsgebiet zugeordnet werden.
warning 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)

note 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

note 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
application Beispiel
  • 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
...

warning 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

note 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

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

Autonomer Modulaufruf

target-blue Ziel

  • Beim Aufruf von Modulen darf das Untermodul vom Ausgangsmodul keine Anweisungen erhalten, die das Verhalten des Untermoduls beeinflussen.

note Vereinbarungen

  • Module müssen mit Hilfe von Python so gecustomized werden, dass sie die auszuführende Aktion beim Aufruf selbst verwalten können.
  • Nach dem Modulaufruf darf kein Menüpunktbefehl folgen.
  • Als Filterkriterium werden nur noch @L-Variablen verwendet, keine @Ds.
  • Modulnummern werden nicht in Python fest programmiert, sondern die Modulnummern sind in globalen Variablen zu speichern und aus diesen auszulesen.

note Details

Inkarnationen

note Regel

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

Startup-Module

note 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

note 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

note 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

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

Customizing in Budgetbereichen

info 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.ä.)
Topic revision: r21 - 2019-05-31 - 10:38:18 - IrinaZieger








 
  • Suche in Topic-Namen

  • Suche in Topic-Inhalten