Lust auf eine Open-Source Lösung für universelle Java Client-Technologie?

[hohwille]

Liebe Java-Entwickler,

bitte schaut Euch mal mein Statement hier an:
https://github.com/m-m-m/mmm/wiki/Rescue-the-java-world

Mit einiger Unterstützung kann das die Rettung werden.

Danke
Jörg

 

[KSG9|sebastian]

Hab mich mal durchgewühlt...aber mir fehlt so ein wenig der Unterschied zu den anderen tausend Frameworks?!
Warum nichtGWT alleine oder z.B Vaadin? Was unterscheidet dein Framework von den anderen? Alleinstellungsmerkmale?

 

[hohwille]

Hi Sebastian,

danke für das Interesse.

In dem Text war ein Link auf die Alleinstellungsmerkmale:
net.sf.mmm.client.ui.api (JavaDocs for mmm 1.0.0)

Der Mehrwert ist, dass man über die gleiche API bald GUIs für Web/GWT, Swing, SWT und vermutlich auch Andorid bauen kann. Ziel des ganzen ist langfristig auch eine API zu standardisieren. Das wird alles ein langer Weg, aber mit etwas Unterstützung wird das gelingen...

GWT selbst ist viel zu "low-level". Die Testbarkeit bei GWT-Apps ist extrem schwierig und in der Entwicklung ist man vor allem mit Warten beschäftigt. Hier wird mein Projekt weiterhelfen.
Die fertige Lösung ist nicht da, aber es ist schon vieles am enstehen.
Wird auch alles HTML5 - bis das fertig ist, wird das Marktreif sein. Auch das ist ein Alleinstellungsmerkmal, denn die ganze Legacy-Katastrophe anderer Frameworks besteht erst gar nicht.

Jörg

 

[Spacerat]

Nein, kein Interesse... um eine solche Technologie zu entwickeln, müssen erstmal die Schwachpunkte der bestehenden Frameworks ausgiebig ausgelotet werden. Es nützt nichts, zu sagen, ein Framework hätte Schwachstellen, wenn man selbst unfähig ist, diese nicht selber erneut zu implementieren oder gar zu verwenden.

I also want to create implementations that adapt from this API to existing native UI-technolgies. And I have already done this for GWT and in previous versions for Swing and SWT.

Meine ureigenste Standardisierung in Sachen Datentypen flüstert mir grad', dass ich soweit auch schon war, wobei alle Implementationen anders aussahen und damit weit entfernt von irgendwelchen Standards waren. Man brauchte also ein und das selbe Framework in der jeweils passenden Version, obwohl man selbst nur für eine Plattform entwickelt hat.

 

[hohwille]

> um eine solche Technologie zu entwickeln,
> müssen erstmal die Schwachpunkte der bestehenden Frameworks ausgiebig ausgelotet werden.

Ich habe über 10 Jahre private und berufliche Erfahrung mit diversen Web-Frameworks gesammelt. Mir sind sehr viele der Schwachpunkte bekannt.

> Es nützt nichts, zu sagen, ein Framework hätte Schwachstellen,
> wenn man selbst unfähig ist, diese nicht selber erneut zu
> implementieren oder gar zu verwenden.

Warum solche Angriffe wie "wenn man selbst unfähig ist" ?
Ich will nicht GWT neu bauen und ich will auch kein Swing oder SWT neu bauen.
Von den untersten Schichten her lösen diese Frameworks bereits die richtigen Probleme.
Aber alle diese Frameworks bieten die gleichen Widgets haben jedoch keine API in Form von Interfaces. Man muss sich also für eines entscheiden. Will man die Entscheidung ändern muss man fast von vorne anfangen. Ich denke eine gemeinsame API dafür ist etwas, dass in Java einfach fehlt.

> Meine ureigenste Standardisierung in Sachen Datentypen flüstert mir grad',
> dass ich soweit auch schon war, wobei alle Implementationen anders aussahen
> und damit weit entfernt von irgendwelchen Standards waren.
> Man brauchte also ein und das selbe Framework in der jeweils passenden Version,
> obwohl man selbst nur für eine Plattform entwickelt hat.

Woher kommt dieses Urteil? Wurde hierzu die angebotene Lösung aus meinem Projekt überhaupt analysiert?

 

[bERt0r]

Was mir nicht ganz klar is: Willst du mit deinem Framework dann Swing/GWT/SWT/etc Code erzeugen oder soll das alles bisherige ersetzen?

 

[Noctarius]

Nein wenn ich es richtig verstanden habe will einen einen allgemeinen Abstraktionslayer erstellen, welcher die darunter liegenden UI Implementierungen wegkapselt und noch oben hin ein gemeinsames Set von Interfaces zur Verfügung stellt.

Mein Problem damit, solche Ansätze gab es schon einige und du läufst immer gegen das Problem:
Finde den kleinsten gemeinsamen Nenner, ergo finde UI-Components welche von allen Frameworks unterstützt werden. Das fängt schon bei Dingen wie Layout-Managern an und hört damit auf, das viele sehr typische Elemente in gewissen Frameworks wegfallen, weil die anderen sie nicht bieten oder man muss sie selber nachimplementieren (was den Aufwand ungemein in die Höhe treibt).

 

[Spacerat]

Sorry... sollte kein Angriff sein, zumal die Idee erstens nicht schlecht ist und zweitens ich eine ähnliche Idee in Sachen Dateiformate habe und diese auch (notfalls im Alleingang) umsetzen werde. Aber wenn ich lese, dass man bei seinem Vorhaben auf bereits Bestehendes fundiert (das hatte ich auch schon...), ist dass mit "gemeinsam" so eine Sache, denn leider ist es so, dass man eigentlich komplett neu anfangen müsste, zumindest damit, was den Inhalt der Top-Level-Frames angeht. Einen Top-Level-Frame bekommt man ja glücklicherweise überall, nur ob man diesen auch überall undekoriert bekommt ist die zweite Frage.
Die Schwachpunkte von solchen Widget-Toolkits beschränken sich aber nicht nur auf das Öffnen und Schliessen von Fenstern oder dem Hinzufügen und Entfernen von Komponenten, sondern in erster Linie auch darauf, dass man auch mal etwas Anzeigen möchte. Grafik, Schrift, dass alles will geladen werden und (evtl. per Paintkontext) auf die Oberfläche gebracht werden. Wie stellst du dir das vor? Andersrum könntest du jetzt fragen, wie ich per DT_Lib geladene Bilder überall anzeigen wollte. Die Antwort ist recht simpel... Mit 'nem neuen Widget-Toolkit, was auf Interfaces basiert und sich über 'nen Service 'nen undekorierten Top-Level-Frame (@Noctarius: das wäre der kleinste gemeinsame Nenner) der jeweiligen Oberfläche holt, auf dem es grad' läuft.
Kurzum: Ich denke mal, wenn du an dem Punkt angekommen bist, wo es um die Implementation einer "paint(Graphics g)" ähnlichen Methode geht, wirst du wissen, wovon ich hier fasel.

 

[hohwille]

Nein wenn ich es richtig verstanden habe will einen einen allgemeinen Abstraktionslayer erstellen, welcher die darunter liegenden UI Implementierungen wegkapselt und noch oben hin ein gemeinsames Set von Interfaces zur Verfügung stellt.

Mein Problem damit, solche Ansätze gab es schon einige und du läufst immer gegen das Problem:
Finde den kleinsten gemeinsamen Nenner, ergo finde UI-Components welche von allen Frameworks unterstützt werden. Das fängt schon bei Dingen wie Layout-Managern an und hört damit auf, das viele sehr typische Elemente in gewissen Frameworks wegfallen, weil die anderen sie nicht bieten oder man muss sie selber nachimplementieren (was den Aufwand ungemein in die Höhe treibt).

Richtig verstanden 🙂
Das mit den Layout-Managern habe ich bereits per Proof-Of-Concept hinbekommen. In Swing und SWT ist das für mich zwar die Hölle, aber für den API-Nutzer ist es gut, weil er sich um so einen murks nicht mehr kümmern muss. Swing hat da auch alles falsch gemacht mit Object constraints, etc.

 

[hohwille]

Kurzum: Ich denke mal, wenn du an dem Punkt angekommen bist, wo es um die Implementation einer "paint(Graphics g)" ähnlichen Methode geht, wirst du wissen, wovon ich hier fasel.

Ist alles schon da von der Basis:
Canvas (Google Web Toolkit Javadoc)

Das zu Wrappen ist nicht so schwer. Die API von Java2d gibt das auch locker her.

Ich will aber erst mal gar nicht pixelgenaue UIs und setzen von einzelnen Pixeln anbieten oder Fenster ohne Rand. Ich will einen Rich Client effizient bauen können, der aus hunderten von Dialogen besteht, mit komplexen Eingabeformularen, Validierung, Databinding, Navigation, Back-Button, etc.

Mein Eindruck ist nur leider, dass ich in diesem Forum nur rumdiskutieren werde, aber keine OSS Entwickler finde...

 

[Spacerat]

Ist alles schon da von der Basis:
Canvas (Google Web Toolkit Javadoc)

Das zu Wrappen ist nicht so schwer. Die API von Java2d gibt das auch locker her.

Ich will aber erst mal gar nicht pixelgenaue UIs und setzen von einzelnen Pixeln anbieten oder Fenster ohne Rand. Ich will einen Rich Client effizient bauen können, der aus hunderten von Dialogen besteht, mit komplexen Eingabeformularen, Validierung, Databinding, Navigation, Back-Button, etc.

Mein Eindruck ist nur leider, dass ich in diesem Forum nur rumdiskutieren werde, aber keine OSS Entwickler finde...

Ist auch 'ne Idee, den ganzen Google-Kram nach Oracle-Java zu wrappen (ich hatte die natürlich noch nicht).
Fenster ohne Rand waren zunächst einfacher, denn damit liessen sich schon mal Grafiken (sogar Animationen) und Schrift überall hinpinseln wo man wollte (z.B. in den Texturbuffer eines LWJGL-Kontext). Der Nachteil dabei, dass man nun all die bereits vorhandenen Widgets und Layoutmanager gar nicht mehr verwenden kann und so fängt man wieder von vorne an und begeht am Ende wieder genau die selben Fehler, die man eigentlich ausmerzen wollte.

 

[Noctarius]

Mein Eindruck ist nur leider, dass ich in diesem Forum nur rumdiskutieren werde, aber keine OSS Entwickler finde...

Naja wie man an einigen Signaturen sieht, gibt es hier genug OSS Entwickler 😛