Guten Morgen allerseits
Mein aktuelles Projekt, wie ihr vielleicht der Überschrift entnommen habt, heißt "x3j".
Als ich irgendwann mal wieder unübersichtlichen Code mit BranchGroups, TransformGroups und was weiß ich geschrieben habe, hab ich mich gefragt, ob es nicht sinnvoller wäre, einen solchen Scenegraph in XML zu beschreiben. Herausgekommen ist jetzt erstmal eine erste Betaversion, die zwar schon funktioniert, der aber noch einiges fehlt. Das Ganze trennt die Oberfläche von der Java-Logik und ist also auch von dieser Seite aus gesehen eine gute Sache.
Wie gesagt - es ist noch lang nicht fertig. Die Frage ist jetzt: Findet ihr das Sinnvoll? Könnt ihr euch vorstellen, dass irgendjemand sowas benutzen würde? Gibt es sowas schon und ich war nur zu doof zu googlen? Die Frage ist nämlich, ob ich das jetzt weitermache, evtl. auf einer Plattform wie Sourceforge, oder ob ich das halt von dem Punkt hier aus immer soweit weiterbaue, wie ich es eben gerade brauche.
Features:
Die XML-Struktur besteht aus 4 großen Bereichen. <meta> ist ähnlich wie <head> in HTML, innerhalb von <canvas> stehen die eigentlichen scene graphs. Dann gibt es <pattern> - der (mit Argumenten veränderbare) Inhalt eines pattern kann innerhalb eines <canvas> mit einem <patternlink> eigebaut werden.
Dazu kommen <type>s. Types sind mit Klassen in der OOP vergleichbar; für nahezu jedes XML Element kann über das Attribut type eine Instanz des types erstellt werden. Wozu das gut ist? Innerhalb von types steht JavaScript-Code in Funktionen / Methoden. Jedes Element bietet events an, wenn das event ausgelöst wird, wird die entsprechende Funktion des types aufgerufen. Das JavaScript kann natürlich für die Übersicht auch in andere Dateien ausgelagert werden.
Für das Ganze gibts nochmal ne extra-Dokumentation (doc/types.txt). Ich hab die allerdings in eclipse geschrieben, und meine sämtlichen anderen Editoren (notepad, textpad, ...) machen die Tabstopps anders, so dass das etwas unfein aussieht - da hätt ich mal früher dran denken sollen, muss überarbeitet werden (vllt als HTML)
Damit kann simpler Code, der nicht zur eigentlichen Logik gehört, in die Datei miteingebunden werden. Theoretisch ist es dadurch natürlich auch möglich, innerhalb einer x3j-Datei ein komplettes, beliebiges Programm zu schreiben (man kann im onLoad-Event des canvas das Canvas3D einem anderen Container hinzufügen, dadurch wird es sonst nirgendwo mehr gezeigt, und man kann irgendwas komplett anderes anzeigen). Sinnvoll ist das allerdings nicht Für sinnvoller halte ich z.B., die x3j-Datei aus eigenem Java-Code heraus aufzurufen und dann innerhalb von event im x3j - wenn es was größeres ist - wieder eigenen Java-Code in der Programmlogik aufzurufen.
Für unterhalb des <canvas> tags sind bereits XML-tags für die meisten Klassen in javax.media.j3d geschrieben. Auch von deren Attributen ist ein großteil beschrieben und wird vom Parser erkannt.
Es gibt einen Editor, bei dem man sehr einfach und relativ schnell auf Knopfdruck das Ergebnis des Codes sehen kann. Wenn Jaxe installiert ist, wird übrigens Jaxe innerhalb des x3j-Editors als XML-Editor verwendet.
Beispiel:
(zeigt nichts vom eigentlichen SceneGraph, das wäre dann zu lang geworden. Ladet das zip-Archiv runter, da sind noch paar mehr Beispiele)
To Do:
Download:
http://home.arcor.de/sidiousx/X3J Beta Release 1.zip
Das ganze ist bisher in meiner "Privat-Bibliothek" namens IlluLib integriert, da ich dachte, das Projekt würde kleiner werden - außerdem ist es noch mit einigen anderen Klassen von da verzahnt Das Archiv enthält: Die komplette IlluLib als jar, 2 Windows-cmd-Dateien um den Editor zu starten / um eine x3j-Datei anzuzeigen (Editor.cmd am Besten editieren und den Pfad zum lib-Ordner von Jaxe einfügen!), die sourcen von x3j, und die Javadoc der gesamten IlluLib (ganz unten ist x3j, de.illu.x3j.*)
Benötigt wird Java 6 - im Endeffekt werd ich aber schauen, dass es auf Java 5 läuft. Das Problem ist, dass ich javax.script extensiv nutze, und das ist bei Java 5 nicht dabei (aber ich kann irgendwie auch da ScriptEngines einbinden, ich hab das nur noch nie gemacht).
Screenshot vom X3JEditor
Mein aktuelles Projekt, wie ihr vielleicht der Überschrift entnommen habt, heißt "x3j".
Als ich irgendwann mal wieder unübersichtlichen Code mit BranchGroups, TransformGroups und was weiß ich geschrieben habe, hab ich mich gefragt, ob es nicht sinnvoller wäre, einen solchen Scenegraph in XML zu beschreiben. Herausgekommen ist jetzt erstmal eine erste Betaversion, die zwar schon funktioniert, der aber noch einiges fehlt. Das Ganze trennt die Oberfläche von der Java-Logik und ist also auch von dieser Seite aus gesehen eine gute Sache.
Wie gesagt - es ist noch lang nicht fertig. Die Frage ist jetzt: Findet ihr das Sinnvoll? Könnt ihr euch vorstellen, dass irgendjemand sowas benutzen würde? Gibt es sowas schon und ich war nur zu doof zu googlen? Die Frage ist nämlich, ob ich das jetzt weitermache, evtl. auf einer Plattform wie Sourceforge, oder ob ich das halt von dem Punkt hier aus immer soweit weiterbaue, wie ich es eben gerade brauche.
Features:
Die XML-Struktur besteht aus 4 großen Bereichen. <meta> ist ähnlich wie <head> in HTML, innerhalb von <canvas> stehen die eigentlichen scene graphs. Dann gibt es <pattern> - der (mit Argumenten veränderbare) Inhalt eines pattern kann innerhalb eines <canvas> mit einem <patternlink> eigebaut werden.
Dazu kommen <type>s. Types sind mit Klassen in der OOP vergleichbar; für nahezu jedes XML Element kann über das Attribut type eine Instanz des types erstellt werden. Wozu das gut ist? Innerhalb von types steht JavaScript-Code in Funktionen / Methoden. Jedes Element bietet events an, wenn das event ausgelöst wird, wird die entsprechende Funktion des types aufgerufen. Das JavaScript kann natürlich für die Übersicht auch in andere Dateien ausgelagert werden.
Für das Ganze gibts nochmal ne extra-Dokumentation (doc/types.txt). Ich hab die allerdings in eclipse geschrieben, und meine sämtlichen anderen Editoren (notepad, textpad, ...) machen die Tabstopps anders, so dass das etwas unfein aussieht - da hätt ich mal früher dran denken sollen, muss überarbeitet werden (vllt als HTML)
Damit kann simpler Code, der nicht zur eigentlichen Logik gehört, in die Datei miteingebunden werden. Theoretisch ist es dadurch natürlich auch möglich, innerhalb einer x3j-Datei ein komplettes, beliebiges Programm zu schreiben (man kann im onLoad-Event des canvas das Canvas3D einem anderen Container hinzufügen, dadurch wird es sonst nirgendwo mehr gezeigt, und man kann irgendwas komplett anderes anzeigen). Sinnvoll ist das allerdings nicht Für sinnvoller halte ich z.B., die x3j-Datei aus eigenem Java-Code heraus aufzurufen und dann innerhalb von event im x3j - wenn es was größeres ist - wieder eigenen Java-Code in der Programmlogik aufzurufen.
Für unterhalb des <canvas> tags sind bereits XML-tags für die meisten Klassen in javax.media.j3d geschrieben. Auch von deren Attributen ist ein großteil beschrieben und wird vom Parser erkannt.
Es gibt einen Editor, bei dem man sehr einfach und relativ schnell auf Knopfdruck das Ergebnis des Codes sehen kann. Wenn Jaxe installiert ist, wird übrigens Jaxe innerhalb des x3j-Editors als XML-Editor verwendet.
Beispiel:
Code:
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE x3j SYSTEM "x3j.dtd">
<x3j>
<meta>
<information key="Example" value="Simple Scenegraph / Hello, World"/>
<information key="Author" value="Illuvatar"/>
</meta>
<type name="Main">
function onMouseClick()
{
alert ("Hello, World");
}
</type>
<canvas type="Main">
<helper setcam="nominal" antialiasing="on" rotatingcolorcube="add">
<orbitbehavior/>
</helper>
<branchgroup>
</branchgroup>
</canvas>
</x3j>
To Do:
Größere Features
- Umwandlung der Beschreibungssprache von dtd in XML-Schema (warum hab ich eigentlich je dtd genommen?) - und da dann auch einiges nochmal ändern (einheitliche Darstellung von gleichen Variablenarten, Reihenfolge der Elemente, etc.)
- Einbauen von <mutator>: Standardisierte Operationen (Highlighting, Alpha ändern, ...) per XML-Tag statt im JavaScript
- <camera>: Position im Scenegraph, der die "Kamera" folgen wird
- Möglichkeit, kleine IWT (braucht euch nicht zu interessieren) und damit auch Swing-Szenen im postRender zu rendern
- evtl. Lokalisierung / I18N vereinfachen
- onXXX Attribute direkt für die Elemente - kein extra type am anderen Ende der Datei notwendig
kleinere Änderungen / Änderungen an der Beschreibung des scene graphs (ausführlicher am Ende der DTD)
- Daten in andere Dateien auslagern (bisher nur mit types möglich)
- Überall noch mehr Attribute, es sind längst nicht alle da (vor allem: <texture>, das hab ich ausgelassen)
- Restliche Elemente implementieren
- Sinnvollere Exceptions werfen, falls nötig; Exceptions schöner anzeigen
- BOUNDS IMPLEMENTIEREN! (danach geht auch soundscape, alternateappearance, fog, etc)
- <geometry> ist noch unausgereift
- <view> einbauen
- mehr JS-Funktionen vordefinieren
Download:
http://home.arcor.de/sidiousx/X3J Beta Release 1.zip
Das ganze ist bisher in meiner "Privat-Bibliothek" namens IlluLib integriert, da ich dachte, das Projekt würde kleiner werden - außerdem ist es noch mit einigen anderen Klassen von da verzahnt Das Archiv enthält: Die komplette IlluLib als jar, 2 Windows-cmd-Dateien um den Editor zu starten / um eine x3j-Datei anzuzeigen (Editor.cmd am Besten editieren und den Pfad zum lib-Ordner von Jaxe einfügen!), die sourcen von x3j, und die Javadoc der gesamten IlluLib (ganz unten ist x3j, de.illu.x3j.*)
Benötigt wird Java 6 - im Endeffekt werd ich aber schauen, dass es auf Java 5 läuft. Das Problem ist, dass ich javax.script extensiv nutze, und das ist bei Java 5 nicht dabei (aber ich kann irgendwie auch da ScriptEngines einbinden, ich hab das nur noch nie gemacht).
Screenshot vom X3JEditor