Girona Wiki

Diese Seite ist nicht editierbar. Sie können den Quelltext sehen, jedoch nicht verändern. Kontaktieren Sie den Administrator, wenn Sie glauben, dass hier ein Fehler vorliegt.

<p> <b>Tombejo</b> </p> <p> <b>Grundsätzliches zur Architektur</b> </p> <p> Server und Client kommunizieren, vom ersten Laden abgesehen, ausschliceßlich über Ajax Requests. Die Logik dazu befindet sich in der Datei js/ajax.js, besonders die Funktion getXMLData, die auch die callback entgegen nimmt, die anschließend ausgeführt wird. Die callbacks die zur Verfügung stehen befinden sich in js/callbacks.js, die standard callback ist die 'onReceiveXMLDefault', soll zusätzlich noch ein Fenster aufgebaut werden, wird die 'onReceiveWindowXML' aufgerufen. </p> <p> Die wesentlichen Teile der Geschäftslogik befinden sich im Ordner classes_new/business_classes. Die module entsprechen im wesentlichen folgendem muster </p> <p> Ordner xyz enthält drei klassen: xyzEntry.class, xyzList.class, xyzTableColumns.class. Entry und List sind selbsterklärend, die Table Columns Klasse fügt Metadaten zu den vorhanden Tabellenspalten des Moduls hinzu. Dies wirkt sich insbesondere auf die Listen-Anzeige aus. </p> <p> Die zu ladenden Felder der Liste werden im Feld "standardColumns" abgelegt, die Methode "setColumnProperties" wird aufgerufen, wenn es sich um eine Hauptliste handelt (also beim klick auf ein Modul vom Startbildschirm), die Methode "setSublistColumnProperties" wird aufgerufen, wenn es sich um eine Subliste handelt. Insbesondere bei Contacts, tabelle ol_nadress, unterscheiden sich diese Methoden. </p> <p> Sollen Felder dargestellt werden, die nicht in der Datenbank vorhanden sind, sondern errechnet werden, muss eine entsprechende Zeile hinzugefügt werden (wichtig ist hier vor allem isDBCOl ⇒ false): </p> <pre class="code">$this -&gt; columnDefinitions [ "column_abc" ] = new ColumnDefinition( array ( "db_col" =&gt; " column_abc " , "isDBCol" =&gt; false , "column_type" =&gt; ColumnDefinition:: TYPE_STRING , "list_column_width" =&gt; "15%" , "isSearch" =&gt; false , "isDisplay" =&gt; true )) ;\\ </pre><p> </p> <p> Ein Beispiel ist der Name der Druckvorlage, 'printtplname' in Ol_InvoiceTableColumns </p> <p> <br/> <br/> <br/> <b>GHAUPT</b> <br/> <br/> der Zentrale Datensatz des Tombejo Friedhofs ist der GHAUPT. <br/> <br/> Auf Datenbank-Ebene ist der primärschlüssel eines GHAUPTs die RECNO, der sekundärschlüssel der KINDEX, zusammen mit der MANDANT ID. Das bedeutet, sowohl durch die RECNO als auch durch KINDEX und MANDANT_ID ist der GHAUPT eindeutig spezifiziert. RECNO wird alleine hochgezählt, der KINDEX in Abhängigkeit von der MANDANT_ID. Ein weiteres Datenbank Feld ist die ARCHIV_ID. Diese ist immer erst einmal 0. Wird ein GHAUPT gelöscht (archiviert), wird diese ARCHIV_ID auf 1 gesetzt, bei einer weiteren archvierung entsprechend auf 2… Nach einer Archivierung wird in der Regel ein neuer GHAUPT an der gleichen Position erzeugt.<br/> <br/> In der realen Welt entspricht ein GHAUPT einer Grabstätte. Spezfiziert ist diese im wesentlichen durch vier Parameter:<br/> FNR (Friedhof), ABTL (Abteilung), REIHE und STELLE. FNR und ABTL sind Fremdschlüssel, gemeinsam mit der Mandant_id. FNR auf OL_FRIEDHOF(FNR) und FNR+ABTL auf OL_STFELDER(AFNR,ANR). Siehe die jeweiligen Kapitel.<br/> <br/> Ein GHAUPT kann über mehrere Stellen gehen. Daher gibt es noch das Feld STELLEBIS. Dort sollte eine Stellennummer stehen, die größer oder gleich dem Wert in STELLE ist. Steht in STELLE 004 und in STELLEBIS 007, so erstreckt sich der GHAUPT über 4 Stellen: 004,005,006 und 007. Das spielt z.B. beim Hinzufügen von neuen Grabstellen eine Rolle.<br/> <br/> <br/> <b>HAUPT01</b> <br/> <br/> HAUPT01 steht in einer one-to-many-relation zu GHAUPT. Zu jedem HAUPT01 gibt es genau einen GHAUPT, zu jedem GHAUPT mindestens einen HAUPT01. KINDEX (mit MANDANT_ID) des HAUPT01 verweist auf den dazugehörigen GHAUPT. Der interne sekundärschlüssel des HAUPT01 zum GHAUPT ist der FZEIG. Ein HAUPT01 ist also spezifiziert durch KINDEX, MANDANT_ID und FZEIG. WIE ein GHAUPT hat auch ein HAUPT01 eine ARCHIV_ID, die analog funktioniert.<br/> <br/> In der realen Welt entspricht ein HAUPT01 einer Grabstelle, also einem Verstorbenen innerhalb einer Grabstätte.<br/> Innerhalb des Programms ist der HAUPT01 spezifiziert durch den GHAUPT, zu dem er gehört, und dann drei weiteren Feldern: STELLE, STETYP und STELFD. STELLE entspricht einer der Stellen des dazugehörigen GHAUPT (Vorsicht! Es gibt bisher keine Konsistenzprüfung). STETYP ist der Typ: Erde, Urne, Tiefgrab, Kind oder Columbarium, STELFD eine laufende nummer, die in Abhängigkeit vom STETYP beim erstellen des HAUPT01 Datensatzes erstellt wird. STETYP und STELFD lassen sich nachträglich nicht mehr ändern.<br/> <br/> <br/> <b>Auflösen</b> <br/> <br/> Unter Grab→mehrfachstellen→auflösen. Zu jeder HAUPT01-Stelle des GHAUPT wird ein neuer GHAUPT angelegt, zu dem alle HAUPT01e die die jeweilige Stelle haben, zugeordnet werden. Eine Stelle wird ausgewählt, innerhalb der die Primärdaten des GHAUPTs übernommen werden:<br/> <br/> Beispiel:<br/> <br/> GHAUPT GH mit STELLE 005, STELLEBIS 010: <br/> 4 HAUPT01 :<br/> H01A mit STELLE 005, STETYP E, STELFD 1<br/> H01B mit STELLE 005, STETYP E, STELFD 2<br/> H01C mit STELLE 006, STETYP E, STELFD 1<br/> H01D mit STELLE 007, STETYP E, STELFD 1<br/> <br/> Nun Auflösung mit ausgewählter Stelle 005.<br/> Danach gibt es 3 GHAUPTs:<br/> <br/> GH1 mit STELLE 005 und STELLEBIS 005, 2 HAUPT01e: 005/E1, 005/E2<br/> GH2 mit STELLE 006 und STELLEBIS 006, 1 HAUPT01 006/E1<br/> GH3 mit STELLE 007 und STELLEBIS 007, 1 HAUPT01 007/E1<br/> <br/> Im GH1 sind alle primärdaten vom ursprünglichen GHAUPT hinterlegt (auf Datenbankebene ist GH1 der Ursprüngliche GHAUPT mit neuer STELLE und STELLEBIS).<br/> <br/> <br/> <b>Verbinden</b> <br/> Unter Grab→mehrfachstellen→verbinden. </p> <p> Es erscheint der "Verbinden" Dialog. Im Gegensatz zum Auflösen Dialog hat dieser keinen Bezug zum GHAUPT, aus dem man kommt. Es geht hier darum, zwei Grabstätten auszusuchen, die, gemeinsam mit den zwischen Ihnen liegenden, in eine gemeinsame Grabstätte (GHAUPT) verschmelzen, in der alle HAUPT01 dieser Grabstätten liegen. Zuoberst befindet sich eine Suchleiste, in der man sich den Bereich auswählen kann, in dem die zu verschmelzenden Grabstätten liegen. Es ist erforderlich, dass diese Friedhof, Abteilung und Reihe gemeinsam haben, um miteinander zu verschmelzen. </p> <p> Aus der unteren List lässt sich ein Anfangs- und (mit Shift) Endpunkt anklicken. Die markierten Gräber werden verschmolzen. Es gibt außerdem Eingabefelder für den neuen Grabnamen und die Felder "stelle" und "stellebis". Anhand des Radiobutton wird entschieden, ob das erste oder letzte GHAUPT derjenige ist, auf dem die ganzen HAUPT01 landen. Alle anderen GHAUPTS, die ja nun keine HAUPT01 mehr haben, werden gelöscht. Das ist die einzige Stelle im Programm (neben Verbinden über Kopf), an der GHAUPTs gelöscht und nicht archiviert werden. </p> <p> <b>Verbinden über Kopf</b> <br/> Unter Grab→mehrfachstellen→verbinden über Kopf. </p> <p> Dieser Dialog ist recht ähnlich wie der Verbinden Dialog. Es werden dieses mal genau zwei Grabstätten verschmolzen, die Friedhof und Abteilung gleich, aber NICHT die gleiche Reihe haben müssen. Von daher kann neben Grabnamen, Stelle und Stellebis auch die Reihe für die neue GHAUPT Stelle angegeben werden. Es gibt außerdem noch einen check button, der überprüft ob die neue Grabnummer in Ordnung ist, oder gegen einen Constraint verstößt. (&lt;nowiki>&#42;&lt;/nowiki>Genauer&lt;nowiki>&#42;&lt;/nowiki>). Standardmäßig bekommet Reihe den Wert GHAUPT1["reihe"] - GHAUPT2["reihe"], also z.b. 3-4. Stelle bekommt den Wert GHAUPT1["stelle"]-GHAUPT1["reihe"], stellebis bekommt GHAUPT2["stelle"]-GHAUPT2["reihe"]. </p> <p> <br/> <br/> <br/> <br/> <br/> <b>Verlegen </b> </p>