MyTISM - Ein Datenbank- und Anwendungs-Framework

FIXME: Besteht aus Include, Entity und Generator

Einleitender Tag: <Schema BEFEHLE>

Schliessender Tag: </Schema>

<Entity name="Person" extends="CBO" plural="Personen" folder="Kontakte">
  <code custom="true"/>
  <ui description="Nachname(', 'Vorname)"/>
</Entity>
        

<attr name="Adressen" singular="Adresse" type="Kontakt" relation="1-n"
            dependent="true" itemProperty="Position">

	Anmerkung
	vgl. de/ipcon/schema/generators/CoreData.nrx und Klassen in de/ipcon/schema/generators/coredata

Füllt die Datenbank mit grundlegenden, benötigten Daten/Objekten:

1.2.1. Zusätzliche, vorgebaute Strukturelemente

Neben den automatisch erzeugten Strukturelementen können auch zusätzliche, vorgebaute Formulare, Schablonen und Lesezeichen automatisch in die Datenbank eingespielt werden. Diese müssen in Verzeichnis de/ipcon/db/core/resources abgelegt werden. Das Format und die Benamsung entspricht dem Format und der Benamsung der mittels Formularsynchronisation (siehe Nutzerdoku) exportierten Dateien, d.h. exportierte Dateien können direkt übernommen werden.

Beim Bauen von MyTISM-Kernel.jar werden die Dateien zusammengesucht und in eine Liste ("ResourceIndex") eingetragen und in das Jar aufgenommen. Beim Aufruf des Coredata-Generators wird diese Liste ausgelesen, die entsprechenden Dateien/Definitionen werden aus dem Jar geladen und die entsprechenden Objekte in der DB angelegt bzw. aktualisiert. Die Dateinamen sind übrigens frei wählbar, lediglich die Endung muss passend zum Typ der enthaltenen Daten sein (*.tpl.xml = Schablone, *.frm.xml = Formular, *.bkm.xml = Lesezeichen).

Folgende Angaben werden z.Zt. unterstützt:

<Root-Element>

Der Name des Root-Elements gibt den Typ der Daten an, also "Formular", "Schablone" oder "Lesezeichen"

Name

"Name"-Attribut des Root-Elements setzt den Namen des Objekts - an sich frei wählbar, Konvention aber "<Entityname> (Vorgebaut)" oder "<Entityname> (Vorgebaut; <Kommentar>)" wenn es mehrere Versionen gibt.

ElterPfad

"ElterPfad"-Attribut des Root-Elements gibt den Ordner an, in dem das Objekt abgelegt werden soll; durch "/" getrennte Ordner-Namen, sollte einer der Ordner (noch) nicht existieren, wird er automatisch angelegt.

Prioritaet

"Prioritaet"-Attribut des Root-Elements gibt die zuzuweisende Priorität an (je größer desto eher wird das Objekt benutzt); sollte im Allgemeinen aber nicht benutzt werden, es wird automatisch der Standard (-50, gegenüber -100 für Automatik-Strukturelemente) gesetzt.

Tid

"Tid"-Attribut des Root-Elements gibt den zu benutzenden Tid-Code ("Klartext-Identifier") an; sollte im Allgemeinen aber nicht benutzt werden, es wird automatisch ein konsistenter Tid vergeben.

Beschreibung

Eigenes Kind-Element des Root-Elementes; der Text wird als Beschreibung des Objektes benutzt.

BOTyp

Eigenes Kind-Element des Root-Elements; sein "Name"-Attribut gibt an, Objekte welchen Typs mit diesem Strukturelement bearbeitet bzw. angezeigt werden sollen.

Parameter

Eigenes Kind-Element des Root-Elements; sein Text wird als "Parameter"-Wert für das Strukturelement verwendet und enthält die weitergehende Definition, insb. für Formulare.

Formular

(Nur für Schablonen) Eigenes Kind-Element des Root-Elements; sein "Name"-Attribut gibt an, welches Formular von der Schablone für die Bearbeitung des neuen Objekts benutzt werden soll.

Gruppen, Polymorphic

Diese Elemente/Attribute werden z.Zt. noch nicht berücksichtigt. Alle Strukturelemente werden automatisch initial (nur) der Admins-Gruppe zugewiesen.

Beispiel für vorgebautes Formular (weitere finden sich im oben erwähnten Verzeichnis):

<Formular Name="$R{_Benutzer} (Vorgebaut)" ElterPfad="Admins/MyTISM/Benutzerverwaltung">
  <Beschreibung>Vorgebautes, aufger&auml;umteres Benutzer-Formular, mit Gruppierungen der Alarm-
    und Benachrichtigungsinfos und einfacherer, halbautomatischer
    Benachrichtigungskonfiguration.</Beschreibung>
  <Parameter>
    <TabbedView tabPlacement="TOP">
      <!-- ... mehr Definition ... -->
    </TabbedView>
  </Parameter>
  <BOTyp Name="Benutzer"/>
  <Gruppen>
    <Gruppe Name="Benutzer"/>
  </Gruppen>
</Formular>

Für spezifische Projekte gibt es (ausser der manuellen Synchronisation) z.Zt. noch keinen entsprechenden Mechanismus, um projektspezifische Strukturelemente automatisch zu laden. Bei Bedarf ließe sich das aber entsprechend ergänzen.

	Anmerkung
	Wenn ein vorgebautes Strukturelement geändert wurde oder neu hinzugekommen ist, muss vor dem Start des Servers die Datei .checked-initialdata gelöscht werden, damit die Änderungen wirksam werden (in Zukunft wird das wohl automatisch geschehen).

MyTISM bietet eine durchgehende Unterstützung für verschiedene Locales, sowohl für die Übersetzung von Texten und Namen als auch für Ein- und Ausgabe von Zahlen, Daten, etc.

Neben der direkten Benutzung in Programmcode mittels der Methoden L10n.msg() bzw. L10n.applyL10n() gibt es weitere Stellen an denen die Mehrsprachigkeit unterstützt wird.

Im GUI-Client Solstice, an vom Benutzer bearbeitbaren Stellen:

Im GUI-Client Solstice, interne Funktionalität:

In diesen "Texten" können Platzhalter $R{key} eingefügt werden. Diese werden dann automatisch vor der "Benutzung" durch zum aktuellen Locale passende Texte ersetzt.

L10nPackProviderI (z.Zt. de/ipcon/tools/L10n und de/ipcon/db/AbstractClient) halten benannte L10nPacks bereit, welche die diversen Textbausteine in unterschiedlichen Sprachen enthalten, gruppiert mittels entsprechender Schlüssel für jeden Textbaustein.

Beim Auflösen von $R{key}-Platzhaltern z.B. im Formularcode (und ebenso beim direkten Aufruf der L10n.msg()-Methoden) wird eine - je nach Aufrufart bzw. -ort unterschiedliche, und bei den im vorherigen Abschnitt aufgeführten Stellen, automatisch zusammengestellte - Liste der an dieser Stelle beteiligten bzw. relevanten Objekte übergeben (Z.B. für Formulare das Formular-Objekt selbst).

Mittels dieser übergebenen Objekte wird nun eine Liste von relevanten L10nPacks erstellt, in denen mittels des Schlüssels "key" nach den angeforderten Textbausteinen gesucht wird. Wird ein zum Schlüssel passender Textbaustein gefunden, wird seine zur gewünschten Sprache passende Version zurückgeliefert.

	Anmerkung
	Schlüsselnamen dürfen nur Buchstaben, Zahlen, '_', '-', '.', '~' und '/' enthalten.

Die Benamsung bzw. Hierarchie der L10nPacks folgt in der Regel der Klassen- bzw. Paketstruktur der Java-Klassen. In den meisten Fällen bestimmen die Java-Klassen der beteiligten Objekte und die Java-Pakete denen diese angehören die zu durchsuchenden L10nPacks.

	Anmerkung
	L10nPack-Namen dürfen nur Buchstaben, Zahlen, '_', '-' und '.' enthalten, wobei '.' das Trennzeichen zum Aufsplitten der Namen ist.

Dies ist unterschiedlich und hängt davon ab, wo und wie die L10n-Funktionalität genutzt wird, z.B.:

Im Normalfall wird die Liste der L10nPacks für eine Klasse einfach nach der im vorherigen Abschnitt beschriebenen Methode (Klassen + Pakete) erstellt. Ist für eine Klasse aber ein sog. L10nPathCompilerI beim L10n registriert, so bestimmt dieser, welche L10nPacks für die entsprechende Klasse in die Liste aufgenommen werden (siehe z.B. "FormularPathCompiler" in Formular.nrx).

Genauere Informationen finden sich bei den entsprechenden Aufrufen von L10n.applyL10n() bzw. L10n.msg() (bei letzterem nur selten, da dort fast nie ein expliziter "path" übergeben wird und fast immer die oben erwähnte Automatik benutzt wird) im Quellcode von MyTISM. L10n.compilePath() enthält weitere Informationen darüber, wie die Liste der zu durchsuchenden L10nPacks zusammengestellt wird.

Die Texte/Daten für die L10nPacks werden z.Zt. aus zwei Quellen gezogen. Die L10n-Klasse lädt ihre Daten aus Dateien .../resources/*.properties die in den Quellcode-Verzeichnissen liegen und beim Bauen ebenfalls in die JARs eingebunden werden. Daneben lädt der Server noch die in der Datenbank befindlichen L10nBundles in seinen L10nCache.

Die Texte der *.properties-Dateien werden alle "von Hand" angelegt und bearbeitet. Die L10nBundles, etc. werden teilweise automatisch generiert, können aber auch von Hand angelegt und bearbeitet werden (FIXME wobei dabei zu beachten ist, dass automatisch angelegte L10nEntries und L10nResources - aber nicht L10nBundles - teilweise auch automatisch gelöscht werden, wenn z.B. die entsprechenden Entities oder Attribute weggefallen sind).

Für jede im Schema definierte Entität, Beispiel "de.ipcon.db.core.Benannt", werden einige L10n-Daten automatisch angelegt. Diese sind im Beispiel zuerst das L10nBundle "de.ipcon.db.core" mit den L10nResourcen "_Benannt" sowie "_Benannt-s", L10nResources für die Ordner, also hier "Interna" (FIXME ggf. weitere) sowie L10nResources für jedes Attribut der Entität also hier "Name", "Beschreibung" usw.

Desweiteren wird für jede Entität noch ein eigenes Bundle, im Beispiel "de.ipcon.db.core.Benannt", angelegt und dort werden ebenfalls noch einmal wie oben für alle Attribute L10nResources angelegt.

Genauere Informationen finden sich in L10nBundle.initEnvironment() und den dort benutzten Methoden.

FIXME Stichworte

neues Bundle anlegen (de.venice) bzw. in einem bestehenden Bundle (de.venice.bo) was hinzufuegen => schauen, dass das Bundle auch Preloaded wird und auch die PfadPos setzen (0). Wenn trotzdem ein neuer Eintrag nicht direkt gefunden wird, dann kann es noetig sein den Server durchzustarten. Das kann der Fall sein, wenn das Bundle erstmalig auf Preload und/oder PfadPos gesetzt wird.

Einfaches Hochkomma muss "escaped" werden => doppelt schreiben

$R-Tags in Formularen, etc.: Suche nach title=", label=", text=".

Nachfolgende Dokumentation behandelt den Aufbau der eines sogenannten Formulars im de.ipcon.form Package des MyTISM Frameworks. Sie soll den Entwickler in die Lage versetzen, Wünsche des Anwenders an die grafische Oberfläche umzusetzen. Im Gegensatz zu Web-Oberflächen sind diese für den Anwender viel effektiver und schneller bedienbar als die etwas generischeren und graphisch meist viel ansprechenderen, aber dennoch umständlich zu bedienenden Web-Oberflächen. Allerdings ist das Abstraktionsniveau im grafischen Client etwas geringer, um schneller zum Ergebnis zu kommen - manchmal ist es besser, den ein oder anderen Wunsch eines Anwenders zugunsten einer saubereren oder aber auch für eingeschränkte Benutzer (sei es technisch (niedrige Farbe, langsamer Rechner) oder auch körperlich (Farbenblindheit, Kurzsichtigkeit)) bedienbaren Lösung abzulehnen.

Einige Fehler denen ich bei der MyTISM-Entwicklung schon begegnet sind und deren Ursachen bzw. Lösungsmöglichkeiten:

BOMengen bieten, ähnlich wie BOMasken, eine Möglichkeit, BOs zu Gruppen bzw. Mengen zusammenzufassen.

Alle BOMengen haben bestimmte Eigenschaften gemeinsam:

FIXME! (werde später noch ein bisschen was dazu schreiben - sw) - anhand was wird rein- bzw. rausgesynct - Konventionen Dateiname - wofuer Tid - ...