2008-11-26 14 views
7

Meine Firma bewertet derzeit die Entwicklung eines Java FAT Clients. Es sollte eine dynamische GUI unterstützen und so viel Logik wie möglich auf der Serverseite haben. Daher kam die Idee, den Bildschirm als XML mit dem FAT-Client zu schicken, zeigen Sie sie an den Benutzer und die eingegebenen Daten ähnlich wie bei „HTML-Formular“ zurück in einer Struktur schicken wie:Java GUI beschrieben in XML

<fields> 
    <field type="checkbox" name="active" checked="false" x="10" y="10" /> 
    <field type="textbox" name="username" value="dummy" x="10" y="30" /> 
    <field type="selection" name="group" selectedIndex="1" x="10" y="50"> 
    <data index="0">user</data> 
    <data index="1">admin</data> 
    </field> 
    <field type="button" name="ok" x="10" y="70" /> 
    <field type="button" name="cancel" x="10" y="90" /> 
</field> 

Hintergrund
Der Sponsor sucht nach einer Dateneingabe- und Überprüfungsanwendung, die er einfach durch Ändern der Konfiguration an seine Bedürfnisse anpassen kann. Daher müssen wir ihren Administratoren die Möglichkeit geben, so genannte "Bildschirme" (sogenannte Formulare) zu entwerfen und ein Client/Server-System zur Verfügung zu stellen, das es ihnen ermöglicht, diese an ihre Endbenutzer zu verteilen. Eingehende Daten (d. H. Von einem Benutzer eingegebene Daten) werden dann an eine bereits existierende Workflow-Engine weitergeleitet, die die Geschäftslogik verarbeitet.

Frage
Hat jemand da draußen entwickelt etwas ähnliches? Welche Bibliotheken würdest du vorschlagen? Irgendwelche pro & Nachteile? Danke vielmals!

aktualisieren
Vielen Dank für Ihre Eingabe sieht Thinlet sehr vielversprechend sowie JavaFX - Ich werde beide schauen.

+0

Ich denke, die politisch korrekte Bezeichnung ist „dick“ Client :) – Draemon

+0

Nein, die Menschen, die auf Ihrem Business-Anwender mit dem Gießen Verleumdungen verwirren den Ausgängen; -} – ConcernedOfTunbridgeWells

Antwort

2

Als ich zuletzt nach so etwas suchte, waren zwei Optionen Thinlet und Apache Jelly.

Die Pluspunkte waren, dass Sie die Verdrahtung und Konstruktion Ihrer Anwendung von dem Verhalten trennen konnten. Ich bin nicht sicher von der Lebensfähigkeit von ihnen, dies zu tun, aber ich denke, könnte einige Funktionalität für die Übersetzung in ein anderes Toolkit sein, so wie Lazlo in AJAX und Flash übersetzen kann.

Bevor ich diese gefunden hatte, hatte ich ein ähnliches Toolkit geschrieben (als Echo war die Schneide, und Java 1.3 war blutig Rand), basierend auf dem JHTMLEditor. Es funktionierte, aber die Listener liefen in der gleichen VM wie der Renderer.

Das bringt den Punkt, den @Draemon macht, in einem Client/Server-Kontext, würde ich fragen müssen, ob dies eine fruchtbare Möglichkeit ist, das größere Problem zu lösen. Ich vermute, dass Sie eine Menge CPU-Zyklen auf den Client abladen wollen? Vielleicht, wenn Sie ein bisschen mehr hinzufügen, können wir weitere Vorschläge machen? Dies weist auf einen Ansatz hin, bei dem Ihre Anwendung auf dem Desktop als localhost Webserver bereitgestellt wird und Sie Seiten einem lokalen Browser zur Verfügung stellen.

Wenn Sie warten können, würde ich, und warten Sie auf JavaFX, da dies Build-Applets ein gutes Stück mehr deklarative macht, und wird auch auf den ersten Download der Rendering-Bibliothek zu reduzieren.

2

"Es sollte eine dynamische GUI unterstützen und hat so viel Logik wie möglich auf der Serverseite."

Was Sie beschreiben, ist eine Web-App. Der Client ist bereits geschrieben (der Browser) und das XML (ish) -Format ist (X) HTML.

Es wäre möglich, diesen Prozess mit Ihrem eigenen XML-Format und Ihrem eigenen Client neu zu erstellen, aber ich sehe nicht, warum dies notwendig oder wünschenswert ist.

+0

Das Problem ist, dass wir mit den Client-Geräten (zB Rechnungsdrucker, Kartenleser) zugreifen müssen, was mit einem Browser nur schwer zu erreichen ist. – MrG

+0

Rechnung Drucker und Kartenleser haben eine GUI? – Powerlord

+0

können Sie nicht ein Applet für den Zugriff auf die Client-Geräte verwenden? (mit den richtigen Sicherheitseinstellungen natürlich) – Draemon

0

Versuchen Sie QT Jambi. Dadurch können Sie Formularlayouts in QT Designer erstellen und als Deskriptordatei der von Ihnen beschriebenen Art exportieren.

+0

Dies verwendet JNI - wäre dies auf etwas wie einem Mac verfügbar? – jamesh

+0

Überprüfen Sie die Webseite von Troll Tech. QT läuft unter Windows, Linux, OSX und einigen verschiedenen Unix-Varianten. OTOH Ich weiß nicht, ob Jambi für OSX verfügbar ist, aber die Website sollte sagen. – ConcernedOfTunbridgeWells

1

Haben Sie etwas Ähnliches mit SWT getan, obwohl das eine logische Datenstruktur (in diesem Fall ein Anwendungsformularmodell) in eine GUI umgewandelt hat, anstatt die GUI direkt anzugeben. Dadurch konnten wir die GUI in Abhängigkeit von den Clienteigenschaften (PocketPC oder Desktop) umgestalten, da das Datenmodell eher semantisch als diktatorisch war.

Schreiben von XML-Parsern und Generatoren ist einfach. Etwas zu schreiben, um eine Schnittstelle von einem Modell zu generieren, ist weniger einfach, da Sie Beziehungen zwischen GUI-Elementen und den Modellfeldern, auf die sie sich beziehen, speichern müssen, um sie bei Änderungen zu aktualisieren, anstatt die üblichen hartcodierten Listener zu verwenden GUI-Element.

1

Es gibt einige XUL-basierte Toolkits für eine Vielzahl von Sprachen, einschließlich Java. Ich denke Thinlet macht eine sehr einfache XUL für Java, aber es sollte andere geben.

1

Sie senden serialisierte Formulare an den Client und serialisieren die resultierenden Daten. Dies könnte mit Java-Serialisierung, d. H. RMI, erfolgen, aber Firewalls usw. können die Verwendung von RMI im Internet erschweren.

Wenn Sie XML über HTTP auf dem Draht verwenden möchten, können Sie sich java.beans.XMLEncoder ansehen. XMLEncoder ist auf die Serialisierung von UI-Komponenten ausgerichtet, funktioniert aber genauso gut, um POJOs zu serialisieren. Dies sind im Wesentlichen die Modellobjekte, die im FAT-Client mit Benutzereingaben gefüllt werden.

1

Werfen Sie einen Blick auf das Framework vonbiz. nutzt Widgets (xml) und durch Handler coverts sie http://ofbiz.apache.org/