Note

  • This topic contains
    • Don't Dos: They must not be used for customizing in PLANTA project since they can lead to (severe) errors up to system crashes.
    • Rules: They should be considered when customizing in PLANTA project.

Don't Dos

Access Objects

Don't Do

  • Objects that have terminated their life cycle on part of the application (e.g. a module that is closed) must by no means be accessed via Python. Each method/attribute call to a closed module/panel may lead to program instabilities and crashes!

Example

  • The following code leads to a crash since a module object is first closed and then it is attempted to save in it.
...
mod.menu(49)
mod.menu(34)
...
PY

Saving in Value Ranges

Don't Do

  • Saving is not permitted in value ranges.

Example

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

Umlauts in Python Scripts

Don't Do

  • In Python scripts (value ranges, macros, Python modules on the server, and module sub-classes), no umlauts (ä, ü, ö) must be used. This also applies to code lines or comments that have been commented out.

Rules

Customize Relations

Rule

  • Relations are only supported if they are of the same data type.

Note

Assign Modules to Work Areas

Rule

  • Every module which is used must be assigned to a work area.

Note

  • As long as the module customizing is not yet completed, this module can be assigned to an appropriate work area in the Indirect Modules module.

Global Settings (Exchangability of Objects)

Rule

  • In the global settings, all objects used in macros must be stored, e.g.
    • Modules
    • Module Variants
    • Dialog Messages
    • OLEs
  • This ensures a plain exchangability of objects, e.g. modules, without having to search all Python scripts.

Try/Except in Python Code

Rule

  • In Python-Code, Try/Except must only be used if
    • the use is justified in a comment, or
    • a specific error type is intercepted

Example

  • False:
...
try:
    ... # Quellcode, der einen Fehler verursacht
except:
    pass # Keinerlei Fehlerbehandlung
...
PY
  • True:

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

Note

  • If no error type is specified, each error is intercepted. This may lead to undesired behavior.
  • For further information, on the use of Try/Except, click here...

Restart the Server

Rule

  • In case of changes made to the data dictionary (DT412), the server must be restarted due to the preloading.
    • Therefore, the restart_server() Python function is provided by the system.
    • Under Linux, the administrator can restart the server with "/etc/init.d/planta reload".

Session Restart after Customizing Changes

Rule

  • Symbols, colors, and formats are cached, therefore the session must be restarted after changes have been made to them.

Incarnations

Rule

  • For each incarnation which is not output,

Startup Modules

Rule

  • Before opening a startup module that starts another module, you have to check whether this respective module has already been opened.
    • If this is the case, the already opened module is to be focused.
    • If this is not the case, the module is to be opened.

Python IDs

Rule

  • Each DataItem must possess a valid Python ID.
  • Python IDs of standard DIs, data areas, data fields, and Python IDs in the global settings must not be changed.
  • Python IDs of individual data items in standard data tables must begin with L and the license number, e.g., L111_stakeholder
  • In individual data tables, the license number can be omitted.
    • Advantage: If the Python ID pr_id is stored for a DI which contains the project ID, a standard macro can be used to open a project.

DI Name

Rule

  • Use reasonable DI names - e.g. simply name fields "Name" instead of "Apa:Name+first name". The "technical information" can be stored in the note field.

Customize with Functional and Technical Project ID

Information

In standard

  • @L variables are always set to the technical ID since
    • only these data items have an index that speeds up the search.
    • Modules with this preset are usually embedded in workflows in which the successor modules also work with it (not only as a filter, but also in the Python macros for accessing the database).
  • In modules which have a filter with @L on the main project or project, users are unable to change the filter criteria on project level (all project fields receive Filter criterion = in the data fields).
  • In modules, only the functional ID is displayed (the technical ID is displayed in window 9, usually with DF options = and Filter criterion=).

In individual customizing

  • The logic should be considered as well, as far as this is possible.
  • In exceptional cases, you have two options:
    • In the customizer, both IDs are offered for selection and the data field name is changed to increase comprehensibility for the user.
    • The customizer only offers the preset technical ID, and additionally, e.g., the project name.
    • In both cases, users must be advised that they have to enter their own criterion and erase the preset (@L).
  • In most individual modules (especially reports), it is not necessary to preset the technical project ID to the project number. In such cases, only the functional ID is to be displayed and approved (the technical ID is in window 9 and the Filter criterion=).

Customizing in Budget Areas

Information

  • The design of cost and budget areas must always be oriented towards that of the Budget module. This means:
    • Group headings like "Costs" and "Effort" are bold.
    • The "Benefit+Revenues" area is located below the effort.
    • The default font symbol is used (no grayed-out areas, or the like)