`App`

Ein App-Objekt stellt eine Applikation dar und hat folgende Attribute:

idString

Der eindeutige Datenbank-Identifizierer der App.

globalsGlobals

Verweist auf das Globals-Objekt, das globale Informationen enthält.

nameString

Der Name der App.

descriptionString oder None

Die Beschreibung der App.

langString

Die Sprache in der die App angezeigt wird (beispielsweise "de" für Deutsch und "en" für Englisch).

imageFile oder None

Das App-Icon in Original-Größe.

Wird das Icon in einer anderen Größe benötigt, kann scaled_url(…) benutzt werden.

private_uploadsBool

Gibt an, ob auf hochgeladene Dateien dieser App nur von autorisierten Benutzern zugegriffen werden darf.

createdbyUser

Der Besitzer der App.

createdatDatum

Der Zeitpunkt zu dem die App erstellt wurde.

updatedbyUser oder None

Der Benutzer, der die App zuletzt geändert hat. (Wurde die App noch nicht geändert, so ist updatedby None.)

updatedatDatum oder None

Der Zeitpunkt, zu dem die App das letzte Mal geändert wurde. (Wurde die App noch nicht geändert, so ist updatedat None.)

controlsDictionary(String ➝ Control)

Die Definition der Felder der App. Dieses Dictionary ist sortiert, d.h. beim Durchlauf werden die Felder in der Reihenfolge durchlaufen in der sie angelegt wurden. Die Schlüssel in diesem Dictionary sind die Feld-Identifizierer und die Werte sind Control-Objekte.

Normalerweise beinhaltet controls alle Felder des Datensatzes, außer wenn in der Datenquellen-Konfiguration Nur Listenfelder? gesetzt ist, dann werden nur diejenigen Felder übernommen, die unter Konfiguration ‣ Liste ausgewählt wurden.

c_<identifier>Control

Control-Objekte stehen auch über sogenannte „Shortcut“-Attribute zur Verfügung. D.h. dass beispielsweise das Feld vorname das normalerweise unter app.controls.vorname zu finden ist, auch direkt als app.c_vorname zur Verfügung steht.

recordsDictionary(String ➝ Record) oder None

Die Datensätze der App. Dies sind evtl. nicht alle Datensätze, wenn der Benutzer nur eingeschränkte Zugriffrechte besitzt. Dieses Dictionary ist sortiert, die Reihenfolge kann in der Konfiguration der Datenquellen konfiguriert werden. Die Schlüssel des Dictionarys sind die Datensatz-Identifizierer und die Werte sind Record-Objekte.

Wenn in der Datenquellen-Konfiguration Nur Anzahl? gesetzt ist, ist records None.

recordcountInteger oder None

Wenn in der Datenquellen-Konfiguration Nur Anzahl? gesetzt ist, beinhaltet recordcount die Anzahl der Datensätze (ansonsten ist recordcount None).

installationInstallation oder None

Wenn die Aplikation durch einen Installationsvorgang erzeugt wurde, ist installation ein Installation-Objekt. Ansonsten ist installation None.

templatesDictionary(String ➝ UL4-Template)

Alle internen Templates, die in der App definiert sind. Diese Templates können unter Konfiguration ‣ Erweitert in der Interne Templates-Maske angelegt werden. Die Schlüssel des Dictionarys sind dabei der Identifizierer des Templates und die Werte die UL4-Templates selbst.

Haben Sie als Datenquelle nicht die aktuelle, sondern eine andere App ausgewählt, haben Sie hiermit die Möglichkeit, auf die internen Templates dieser in der Datenquelle konfigurierten App mit zuzugreifen.

t_<identifier>UL4-Template

Template-Objekte stehen auch über sogenannte „Shortcut“-Attribute zur Verfügung. D. h., dass beispielsweise das Template gurk, das normalerweise unter app.templates.gurk zu finden ist, auch direkt als app.t_gurk zur Verfügung steht. Oder als datasources.beispiel.app.t_gurk wenn Sie als Datenquelle eine andere App ausgewählt haben.

categoriesDictionary(String ➝ Category) oder None

Wenn in der Datenquellen-Konfiguration Kategorien etwas ausgewählt ist, enthält categories die Kategorien, denen diese App zugeordnet ist. Die Schlüssel des Dictionarys sind die internen Datenbank-Identifizierer der Kategorie und die Werte sind Category-Objekte.

Ist bei Kategorien nichts ausgewählt, ist categories None.

paramsDictionary(String ➝ AppParameter)

Die Parameter der Applikation (die unter Konfiguration ‣ Erweitert in der Parameter-Maske angelegt werden können). Die Schlüssel des Dictionarys sind die Identifizierer der Parameter. Die Werte sind AppParameter-Objekte.

p_<identifier>AppParameter

AppParameter-Objekte stehen auch über sogenannte „Shortcut“-Attribute zur Verfügung. D. h., dass beispielsweise der App-Parameter beispiel, der normalerweise unter app.params.beispiel zu finden ist, auch direkt als app.p_beispiel zur Verfügung steht.

pv_<identifier>Objekt

Damit kann direkt auf den Wert eines``AppParameter``-Objekts zugegriffen werden. D. h. app.pv_beispiel ist äquivalent zu app.p_beispiel.value (was wiederum zu app.params.beispiel.value äquivalent ist).

viewsDictionary(String ➝ View)

Die verschiedenen Formularvarianten der Applikation (die unter Konfiguration ‣ Eingabe bei Formularvarianten angelegt werden können). Die Schlüssel des Dictionarys sind die Identifizierer der Views. Die Werte sind View-Objekte.

active_viewView

Die aktive Formularvariante. Ist active_view gesetzt (was durch Ändern dieses Attributs im Template getan werden kann, bzw. bei Formular-Templates automatisch passiert), werden beim Setzen von Feld-Werten die in dieser Variante definierten Feld-Restriktionen berücksichtigt (minlength und maxlength für String-Felder, required für alle).

Wird das Attribut active_view gesetzt kann als Wert sowohl ein View-Objekt verwendet werden, als auch die id eines View-Objekts. Dieses View-Objekt muß zu dieser App gehören.

datasourceDataSource

Das DataSource-Objekt das diese App beinhaltet, oder None, wenn es für diese App kein DataSource-Objekt gibt. D.h. es gibt für jede App a immer a.datasource is None or `a.datasource.app is a.

layout_controlsDictionary(String ➝ LayoutControl) oder None

Die Layout-Controls des aktiven Views. Dazu muß es einen aktiven View geben und in der Datenquelle muß bei Felder Alle Felder und Layout-Felder ausgewählt sein. Ansonsten ist layout_controls None.

lc_<identifier>LayoutControl

„Shortcut“-Attribut zum Zugriff auf die Layout-Controls des aktiven Views. app.lc_beispiel ist äquivalent zu app.layout_controls.beispiel.

favoriteBool

Gibt an, ob der aktuelle eingeloggte Benutzer diese App als Favorit festgelegt hat.

menusDictionary(String ➝ MenuItem) oder None

Die zu dieser App konfigurierten Menüs. Die Schlüssel in diesem Dictionary sind die Identifizierer und die Werte sind MenuItem-Objekte.

panelsDictionary(String ➝ Panel) oder None

Die zu dieser App konfigurierten Panels. Die Schlüssel in diesem Dictionary sind die Identifizierer und die Werte sind Panel-Objekte.

insert(**values)Methode(**Objekt) ➝ Record

Mithilfe von insert() kann in der App ein neuer Datensatz angelegt werden. Die Parameter müssen per Schlüsselwort übergeben werden. Der Parametername ist dabei jeweils der Feld-Identifizierer des zu setzenden Feldes. Beispielsweise kann in eine Personen-App mit den Feldern vorname, nachname und geburtstag mittels folgendem Aufruf ein Datensatz eingefügt werden:

<?code record = app.insert(
   vorname="Max",
   nachname="Mustermann",
   geburtsdatum=@(2000-02-29),
)?>

Der zurückgegebene Datensatz wird mit den übergebenen Feldwerten initialisiert und das Attribut id (der eindeutige Datensatz-Identifizierer) ist gesetzt. Jedoch spiegelt der Datensatz keinerlei Änderungen wieder, die evtl. vom System über Datenaktionen durchgeführt wurden.

new_embedded_url(**params)Methode(**Objekt) ➝ String

Gibt die absolute URL zurück für das Eingabe-Formular zum Anlegen neuer Datensätze dieser App. Bei dieser URL ist das Formular in den üblichen LivingApps-Rahmen eingebettet und der Benutzer muß eingeloggt sein um es benutzen zu können.

Mittels params können der URL zusätzliche Parameter übergeben werden. Als Werte werden sowohl Strings unterstützt als auch Listen von Strings (in diesem Fall wird der Parameter mehrmals an die URL angefügt). Außerdem wird beim Wert None der Parameter ignoriert.

Beispiel 1:

<?print app.new_embedded_url()?>

erzeugt:

https://my.living-apps.de/dateneingabe/1234567890abcdef12345678/new

Beispiel 2:

<?print app.new_embedded_url(view="abcdef12345678901234")?>

erzeugt:

https://my.living-apps.de/dateneingabe/1234567890abcdef12345678/new?view=abcdef12345678901234

Beispiel 3:

<?print app.new_embedded_url(a=["17", 23], b=None, c=[today(), None])?>

erzeugt:

https://my.living-apps.de/dateneingabe/1234567890abcdef12345678/new?a=17&a=23&c=2022-11-10

new_standalone_url(**params)Methode(**Objekt) ➝ String

Gibt die absolute URL zurück für das Eingabe-Formular zum Anlegen neuer Datensätze dieser App. Bei dieser URL ist das Formular nicht in den üblichen LivingApps-Rahmen eingebettet sondern unabhängig und kann auch von nicht eingeloggten Benutzern ausgefüllt werden.

Mittels params können der URL zusätzliche Parameter übergeben werden.

Beispiel 1:

<?print app.new_standalone_url()?>

erzeugt:

https://my.living-apps.de/gateway/apps/1234567890abcdef12345678/new

Beispiel 2:

<?print app.new_standalone_url(view="abcdef12345678901234")?>

erzeugt:

https://my.living-apps.de/gateway/apps/1234567890abcdef12345678/new?view=abcdef12345678901234

Beispiel 3:

<?print app.new_standalone_url(a=["17", 23], b=None, c=[today(), None])?>

erzeugt:

https://my.living-apps.de/gateway/apps/1234567890abcdef12345678/new?a=17&a=23&c=2022-11-10

template_url(identifier, record=None, /, **params)Methode(String, Record oder None, **Objekt) ➝ String

Gibt die absolute URL zurück für ein Anzeige-Template mit dem Identifizierer identifier. Ist record None so wird ein Link zu einem Listen-Template generiert, wird für record ein Datensatz übergeben, so wird ein Link zu einem Detail-Template generiert (Die verlinkte App ist dabei die App für die diese Methode aufgerufen wird, nicht die App zu der der Datensatz gehört).

Mittels params können der URL zusätzliche Parameter übergeben werden.

Beispiel 1:

<?print app.template_url("beispiel")?>

erzeugt:

https://my.living-apps.de/gateway/apps/1234567890abcdef12345678?template=beispiel

Beispiel 2:

<?print app.template_url("beispiel", r)?>

erzeugt:

https://my.living-apps.de/gateway/apps/1234567890abcdef12345678/0987654321fedcba1234?template=beispiel

Beispiel 3:

<?print app.template_url("beispiel", x=17, y=23)?>

erzeugt:

https://my.living-apps.de/gateway/apps/1234567890abcdef12345678?template=beispiel&x=17&y=23

home_url()Methode() ➝ String

Gibt die absolute URL zur Detail-Seite einer App zurück.

Beispiel:

<?print app.home_url()?>

erzeugt:

https://my.living-apps.de/apps/1234567890abcdef12345678.htm

datamanagement_url()Methode() ➝ String

Gibt die absolute URL zur Datenmanagement-Seite einer App zurück.

Beispiel:

<?print app.datamanagement_url()?>

erzeugt:

https://my.living-apps.de/_id_36_.htm?uuid=1234567890abcdef12345678&dId=1234567890abcdef12345678&resetInfo=true&templateIdentifier=created_1234567890abcdef12345678

import_url()Methode() ➝ String

Gibt die absolute URL zur Import-Seite einer App zurück.

Beispiel:

<?print app.import_url()?>

erzeugt:

https://my.living-apps.de/import-export/1234567890abcdef12345678.htm

tasks_url()Methode() ➝ String

Gibt die absolute URL zur Aufgaben-Seite einer App zurück.

Beispiel:

<?print app.tasks_url()?>

erzeugt:

https://my.living-apps.de/_id_1073_.htm?uuid=1234567890abcdef12345678&dId=1234567890abcdef12345678&p_tpl_uuid=1234567890abcdef12345678&resetInfo=true&templateIdentifier=created_task_1234567890abcdef12345678

datamanagement_config_url()Methode() ➝ String

Gibt die absolute URL zur Datenmanagement-Konfigurations-Seite einer App zurück.

Beispiel:

<?print app.datamanagement_config_url()?>

erzeugt:

https://my.living-apps.de/datenmanagement-konfigurieren/1234567890abcdef12345678.htm

permissions_url()Methode() ➝ String

Gibt die absolute URL zur Berechtigungs-Seite einer App zurück.

Beispiel:

<?print app.permissions_url()?>

erzeugt:

https://my.living-apps.de/_id_833_.htm?uuid=1234567890abcdef12345678&dId=1234567890abcdef12345678&resetInfo=true

datamanageview_url(identifier)Methode(String) ➝ String

Gibt die absolute URL zu einer Datenauswertungs-Seite im Datenmanagement einer App zurück.

Beispiel:

<?print app.datamanageview_url("beispiel")?>

erzeugt:

https://my.living-apps.de/_id_36_.htm?uuid=1234567890abcdef12345678&dId=1234567890abcdef12345678&resetInfo=true&templateIdentifier=created_1234567890abcdef12345678_datamanage_master_beispiel

seq()Methode() ➝ Number

Gibt einen fortlaufenden Integer-Wert zurück, der innerhalb dieser App eindeutig ist.

send_mail()Methode(from: String oder None, reply_to: String oder None, to: String oder None, cc: String oder None, bcc: String oder None, subject: String oder None, body_text: String oder None, body_html: String oder None, attachments: File oder None) ➝ None

Verschickt eine E-Mail.

Nähere Informationen finden Sie unter E-Mails über die LivingAPI versenden.

customObjekt

Dieses Attribut kann vom Benutzer für beliebige zusätzliche Informationen gesetzt werden.

x_<identifier>Objekt

Es werden beliebige zusätzliche Attribute unterstützt deren Namen mit x_ beginnt.

Neue Datensatzobjekte können angelegt werden, indem das App-Objekt aufgerufen wird. Feld-Werte können als Keyword-Argumente übergeben werden. So erzeugt z. B. datasources.beispiel.app() ein leeres Datensatzobjekt zur App „Beispiel“. Besitzt diese App die Felder vorname, nachname und geburtstag kann mittels folgendem Aufruf ein Datensatz-Objekt mit den entsprechenden Feld-Werten angelegt werden:

<?code record = app(
   vorname="Liv",
   nachname="Logic",
   geburtsdatum=@(2000-02-29),
)?>

Im Gegensatz zu insert() wurde der Datensatz nach diesem Aufruf noch nicht gespeichert, dies erfolgt erst durch den Aufruf von record.save(). Daher sind vorher die Attribute id, createdby, createdat, updatedby und updatedat auch None und werden erst durch den Aufruf von record.save() gesetzt.

Ist eine App nicht explizit in einer Datenquelle konfiguriert, so kann das zugehörige App-Objekt trotzdem innerhalb der LivingAPI auftauchen, wenn ein Datensatz über ein Auswahlfeld auf diese App verweist. In einem solchen Fall ist sowohl records als auch recordcount None.

Wird durch Aufruf des App-Objektes eine neues Datensatz-Object angelegt, und die App hat einen aktiven View so werden die in diesem View konfigurierten Standardwerte für die Felder berücksichtigt.

Außerdem werden bei aktivem View zwar alle Felder des Datensatzes gespeichert, aber Fehler in Feldern, die nicht im aktiven Vies sind werden ignoriert.