de.a_weinert ( Frame4J -- the Java framework de.frame4j... )

Overview

Package

Class

Tree

Deprecated

Index

Help

PREV PACKAGE NEXT PACKAGE

FRAMES NO FRAMES

Package de.a_weinert

Klassenbibliotheken / Framework für Java-Anwendungen
Copyright © 1997 - 2006 Albrecht Weinert.

See:
Description

Interface Summary
StateSerializable	Serialisierung des Objektzustands.

Class Summary
WinApp	Gerüst / Grundlage einer graphischen Java-Anwendung.

Package de.a_weinert Description

Klassenbibliotheken / Framework für Java-Anwendungen
Copyright © 1997 - 2006 Albrecht Weinert.

Inhalt

Beschreibung
Nutzung von App
Zur Bedeutung und Wirkung der .properties-Datei
Zur Platzierung der .properties und .xml-Dateien
Hinweis auf Beispiele für die (Standard-) Vorgehensweise
Hinweis zu Properties für Applets und Servlets
Andere Klassen
Versionshinweise
Nutzungsbedingungen, Copyright

Beschreibung

Dieses Paket de.a_weinert und seine Unterpakete

werden mit zusätzliche Ressourcen und Anwendungen i.A. als aWeinertBib.jar ausgeliefert und (als "installed extension" installiert. Die Pakete stellen stellen eine Ergänzung zum Rahmenwerk — Framework — Frame4J (frame4j.jar) zur Verfügung, das die Erstellung von leistungsfähigen Java-Applikationen sehr vereinfacht. Im Gegensatz zu Frame4J (frame4j.jar) ist aWeinertBib.jar deutschsprachig und nicht allein verwendbar; es baut auf Frame4J auf.

Eine zentrale Bedeutung haben die Klassen App, Prop und AppIO, die wiederkehrende Aufgaben bei "ernsthaften" Java-Applikationen sowie deren Steuerung und Parametrierung über Properties zur Verfügung stellen. Auch graphische Anwendungen bauen sinnvollerweise auf App auf. Dies kann durch direktes Erben geschehen; im Allgemeinen wird man hier aber gleich die zusätzlichen Möglichkeiten der App-Erweiterung WinApp nutzen (siehe dort) dar.

Das Framework trägt auch mehrere wechselnde und sich gegenseitig nutzende (App-) Anwendungen in der selben JMV und Ressourcenumgebung gleichzeitig und im (Server-) Dauerbetrieb.

Durch dieses Framework können alle auf App (bzw. WinApp oder anderen Erben) beruhenden Anwendungen auf einfachste Weise als JMX-Elemente (Java Management Extensions) bedien- und beobachtbar gemacht werden. Jedes App-/WinApp-Erbe ist ein DynamicMBean und ein JMX-Server wird bedarfsweise (automatisch) vom Framework initialisiert und gehandhabt. Bei den B&B-Client-Rechnern ist (für einen recht hohen) Einstieg nur das JDK-Werkzeug JConsole notwendig. Wenn die entsprechenden Zertifikate etc. bereitgestellt sind ist bereits diese Vorgehen sicher.

Für eine solche remote-B&B eines App-Erbes muss dieses im einfachsten Falle lediglich nur eine einzige Programmzeile (registerAsMBean()) enthalten und bei Initialisierung ausführen. Ohne dieses oder entsprechende Aktionen gibt es keine JMX-B&B; es gibt keine Hintertür.

Nutzung von App

Eine Applikation, die die Bibliotheksmöglichkeiten nutzen möchte, muss in ihrer Methode main() eine Instanz einer eigenen Ableitung von App erzeugen. Der empfohlene Ansatz ist es, eine eigene Klasse von App abzuleiten und in ihr die abstrakte Methode doIt() zu implementieren. Diese Methode doIt() stellt dann den (eigentlichen) Start der Anwendung dar.

Das Schema sieht etwa so aus:

   |-------------------------------------------------------|
   |   import de.frame4j.util.*;                           |
   |                                                       |
   |   @MinDoc(                                            |
   |      copyright = "Copyright 2010  A. Weinert",        |
   |      author    = "Albrecht Weinert",                  |
   |      version   = "V.1",                |
   |      lastModified   = "11.02.2010",          |
   |      lastModifiedBy = "A. Weinert",        |
   |      usage   = "start as Java application (-? for help)",  
   |      purpose = "a skeleton App inheritor to work with"
   |   ) public class MyApp extends App {                  |
   |                                                       |
   |     protected int doIt() {                            |
   |         /// ...  tut alles, siehe unten               |
   |         return 0; // 0 ist OK, > 0 nicht OK           |
   |     } // int doIt()                                   |
   |                                                       |
   |     static public void main(String[] args) {          |
   |       try {                                           |
   |         new MyApp().go(args, false);                  |
   |       } catch (Exception e) { // exit nur via ...     |
   |         AppBase.exit(e, INIT_ERROR); // Fehlstart     |
   |       } // exit nur via FrameWork                     |
   |     } // void main(String[])                          |
   |                                                       |
   |  } // class myApp                                     |
   |-------------------------------------------------------|

Eine kleine main-Methode der von App abgeleiteten Klasse muss dann nur, wie gezeigt, den default-Konstruktor dieser abgeleiteten Klasse aufrufen und mit dieser Referenz gleich eine der (von App) geerbten go-Methoden. Dabei wird empfohlen, eine on-line-Dokumentation in Form einer Annotation (Klasse MinDoc) zu erzeugen und die oben gezeigte go-Methode zu verwenden.

Die go-Methode wiederum ruft die in der abgeleiteten Klasse (MyApp im Beispiel) implementierte Methode doIt() auf, der problemlos alle Möglichkeiten der Klasse App oder ihres Erbes WinApp offen stehen.

Insbesondere wurde vor dem Aufruf von doIt() ein Prop-Objekt mit den Eigenschaften der Anwendung erzeugt und die Auswertung weiterer .properties-Dateien, Internationalisierung und Startparameterüberprüfung und -auswertung erledigt. Alle geerbten und zugefügten (Beans-) Eigenschaften des Anwendungsobjekts sind bereits fertig gesetzt; die Klasse Prop ist hier sehr mächtig.

Zur Bedeutung und Wirkung der .properties-Datei

Bei Anwendungen, welche (als App-Erben) die Möglichkeiten von Prop auf die gezeigte Weise nutzen, gelten folgende Hinweise:
Alle öffentlichen Felder — d.h. jede öffentliche Objektvariable — des Objekts der Anwendungsklasse sind Eigenschaften beziehungsweise Properties, welche die Arbeitsweise des Programms steuern.
Sie werden automatisch durch die Programmstartparameter- und Properties-Datei-Auswertung der Klasse Prop gesetzt; siehe u.A. App.go(..) und Prop.setFields(..).
Dies bedeutet auch, dass Default-Angaben (initialiser) zu diesen öffentlichen Feldern durch die zur Anwendung gehörenden Grund-Properties-Dateien überfahren werden können.

Zur Platzierung der .properties-Datei

Zu Anwendungen, welche als App-Erben die Möglichkeiten von Prop auf die genannte Weise nutzen, gehört dann als integraler eine Properties-Datei namens <einfacher Klassenname>.properties. Bei graphischen Anwendungen, sprich WinApp-Erben, kommt i.A. eine XML-Menu-Beschreibung in einer Datei namens <einfacher Klassenname>Mb.xml hinzu. Für die Platzierung dieser Dateien erlaubt beziehungsweise unterstützt die Klasse PropMap drei Möglichkeiten:

im .jar-File der Anwendung neben deren Klassendatei,
im jre/lib-Verzeichnis oder
im aktuellen Verzeichnis.

Sofern möglich und zutreffend, ist diesen Möglichkeiten in der genannten Reihenfolge der Vorzug zu geben. Solche Dateien — die "Grund-.properties" und ggf. .xml-Menus — sind im gegebenen Falle ja ein unverzichtbarer, integraler Bestandteil der Anwendung. Falls Sie in ein .jar-Archiv platziert werden, müssen Sie UTF8 kodiert sein (was man mit dem Tool de.frame4j.UCopy leicht hinbekommt).

Für die Platzierung weiterer .properties-Dateien <einfacher Klassenname>_<lang>.properties etc. und ggf. auch <einfacher Klassenname>Mb_<lang>.xml , die wie in Prop beschrieben, die Anwendung ohne jeden Programmieraufwand (inter-) nationalisieren können, gilt das eben gesagte genau so. Die "Grund-Internationalisierung", i.A. de und en, lässt sich vorzugsweise auch direkt in den Grund-.properties- und -.xml-Dateien darstellen.

Hinweis auf Beispiele für die (Standard-) Vorgehensweise

Als Beispiel kann auch die dort referenzierten Quellen und .properties-Dateien von AskAlert, FuR etc. dienen.

Das entsprechende Vorgehen für graphische auf WinApp beruhende Anwendungen siehe hier. Bewährte Anwendungen, die App beziehungsweise WinApp nutzen, siehe als direkte Erben ("Direct Known Subclasses") jeweils dort und in folgendem Bild.

Bild 1: Bewährte auf WinApp und App beruhende Anwendungen; Assoziationen mit den wichtigsten Hilfsklassen.
(Klicken Sie hier für volle Größe und Schärfe.)

Hinweis zu Properties für Applets und Servlets

Die Klasse Prop erbringt den für Applikationen (App, WinApp) gebotenen Komfort bei der Handhabung von Eigenschaften, Start- und Steuerparametern, (Inter-) Nationalisierung etc. auch Applets und Servlets.

Die Platzierung der .properties-Datei(en) erfolgt dann neben der Klassendatei des Applets bzw. Servlets im selben Verzeichnis — entweder "ausgepackt" oder i.A. dort im selben (deployment-) .jar-File.

Andere Klassen

Das Paket de.a_weinert und seine Unterpakete bieten noch zahlreiche Klassen, die graphische und nicht graphische Anwendungen aber auch Applets vorteilhaft nutzen können. Diese sind unter anderen:

MinDoc: Online-Dokumentation als Annotation,
Prop: Handhabung von Eigenschaften (Properties) und Aufrufparametern,
PropMap: dto.; Elternklasse von Prop und AppLangMap,
AppLangMap: Unterstützung der Vielsprachigkeit (Kern-EU),
DataFile: Handhabung von Dateien und Dateiausgabe,
Input: Handhabung von Eingaben,
TeeWriter: Ein gepufferter Writer mit einer robusten und entkoppelten Verzweigung und weiteren Funktionen,
AppIO: Handhabung der Ein-/Ausgabe für graphische und nicht graphische Java-Anwendungen,
XMLdoc: Unterstützung von XML-Anwendungen,
Complex: komplexe Zahlen,
CFun, SFun: einige mathematische Funktionen,
SerIO: Handhabung von Standardschnittstellen,
SimpleModbusDriver: Prozess-E/A-Treiber, MODBUS-Peripherie,
SimpleMMBoosterDriver: Prozess-E/A-Treiber, Märklin-Motorola-Protokoll (seriell an Booster),
ServeJMBW: Handhabung von JMX,
Time: einfache unaufwändige Handhabung von Zeit- und Kalenderfunktionen.

Das folgende Bild 2 zeigt den Zusammenhang der Elternklassen WinApp bzw. App für graphische und nicht graphische Anwendungen mit einigen dieser unterstützenden Klassen in diesem Framework.

Bild 2: App und WinApp Einbindung in die Graphik-Klassen (universell) für swing und AWT.
(Klicken Sie hier für volle Größe und Schärfe.)

Versionshinweise

Ab Version V02.00 werden die Möglichkeiten von JDK 1.4.2 ohne Rücksicht auf Abwärtskompatibilität genutzt. Dies ist u.A. dadurch gerechtfertigt, dass nunmehr kaum ein Browser -- und sei es nach Installation von JRE + Java-Plug-in -- noch Probleme mit 1.4-erzeugten Applets hat.
Auf frühere Versionen des Frameworks wird hier also nicht mehr eingegangen. Ab 2.36 werden Java 5/6-Möglichkeiten nach und nach genutzt.

Bezüglich JDK-/JRE-Versionen ist es inzwischen sinnvoll, mit JDK1.6.0_17 oder höher zu entwickeln und damit oder dem entsprechenden JRE zu fahren, auch wenn man keine 1.5-features einsetzt. Beim Framework wird inzwischen Java6 vorausgesetzt.

Bei der Verwendung von Java 5 oder 6 (JDK >=1.5.0_y) ist die JMX-Unterstützung integriert, die XML-Handhabung vollständig (Schema) und vieles Andere (fast nur) besser.

Die Versionen V02.62 (-.74) brachten die die Klassen PropMap (als neue Elternklasse von Prop) und AppLangMap und hierauf beruhend u.A. eine noch weitergehende Unterstützung der Internationalisierung.

Ab Version V02.82 steht WinApp-Erben eine einfache, kompakte, internationalisierbare und gut lesbare .xml-Menubalken-Beschreibung (s.o. und 2. Beispiel) zur Verfügung, die für swing- und AWT-Ausprägungen gleichermaßen geeignet ist, und damit gleich das Problem der zwischen JDK1.4.x und JDK1.5.x inkompatiblen swing-Serialisierungen löst.

Ab Version weBib_03-40 wird eine einheitliche Unterstützung für Applikationen, Applets und Servlets durch das Framework sichtbar (und nutzbar).

Nutzungsbedingungen, Copyright

Sie nutzen diese Software auf eigene Verantwortung und eigenes Risiko.
Für Fehler und Schäden wird keine Verantwortung übernommen.
Sie dürfen die Klassendateien und die mitgelieferte Dokumentation frei von Lizenzgebühren verwenden.
Sie dürfen sie, ohne dafür Gebühren zu erheben, weiterverbreiten und auch an die Abnehmer ihrer Software weitergeben, sofern Sie die hier gestellten Bedingungen mit weitergeben und auf diese hinweisen.
Anwendungen des Frameworks und der publizierten Quellen sowie Modifikationen sind dem Autor anzuzeigen.
Im Übrigen gelten die Bedingungen des zugrunde liegenden Frameworks Frame4J.

Anfragen und Meldungen bitte an albrecht@a-weinert.de.
Nach neueren Versionen suchen Sie bitte ausgehend von http://www.a-weinert.de.

Version:: Frameworke: 2.38; Text: 1 (11.02.2010)
Author:: Albrecht Weinert
See Also:: Paketbeschreibung, Nutzungsbedingungen
, App, WinApp, de.a_weinert.math, de.frame4j.io, de.frame4j.graf, de.frame4j.net, de.frame4j.xml