swt/jface, IBM Rich Client, Domino Workplace

[Marinero Atlántico]

Hi,

swt/jface sind Apis für die Entwicklung von Java Clients.
Hinsichtlich des Zwecks also gleich wie awt/swing.
Anders als Swing benutzt es die nativen widgets (Elemente: sowas wie buttons, Eingabefelder, Spreadsheet-Elemente, frames, etc.) des jeweiligen Betriebssystems.
Swing zeichnet seine eigenen und benötigt somit vermutlich theoretisch mehr Ressourcen (wobei sich das bei Java1.4 sehr gebessert hat).
 
Das Benutzen von OS-widgets gilt aus Anwender-Akzeptanz Sicht als sinnvoll. Zufriedene Windows-XP user wie ich wollen gar nicht, dass die GUI Anwendungen anders aussehen, wie ich es von den anderen Windows-XP Anwendungen gewöhnt bin.
Suns Swing Vorläufer Java-AWT verfolgte auch einen nativen Ansatz, hatte aber mehrere Probleme:
- komplexere widgets wie z.B. Tables oder Trees wurden nicht unterstützt.
- doofe Api
- sehr un-objektorientierte API
- nicht besonders effizient programmiert

IBM hatte nach dem Aufkauf der kanadischen Firma OTI Programmierer, die sich mit der Entwicklung von nativen GUI-APIs für Smalltalk sehr gut auskannten.

Ausserdem hat IBM wirklich schlechte Java Clients mit Swing entwickelt (DB2 Controll Center).

Für die neue plattformunabhängige IDE-Plattform Eclipse baute IBM deshalb die neuen APIs swt/jface.

Dabei stellt swt die Grundlagen zur Verfügung und jface ist ein Layer darüber mit Dingen, die das programmieren einfacher machen (einige viel-krempel-in-einer-Methode Klassen, Implementierung von Model View Controller Pattern, etc.).

Lotus Workplace benutzt swt/jface. Eclipse benutzt swt/jface.

Einige besondere features:
- Swing kann integriert werden
- ActiveX-Objekte / OLE kann integriert werden
- drag-and-drop Unterstützung
- sehr gute Fähigkeiten für die Bearbeitung von RichText, ganz besonders im Hinblick auf typische GUI-Funktionalitäten wie Text-Highlighting.

In der Folge will ich mich hier ein bischen zu swt/jface sowie IBM Rich Client auslassen und ein bischen Beispielcode posten, dass ich sicher irgendwo anders geklaut habe.
Ich persönlich finde die api zur Zeit sehr cool, wobei unser eclipse plugin Entwicklungsteam mir schon eine gewisse Unerfahrenheit mit real existierenden Ärgernissen attestiert hat.

Im Grunde ist das eine Alternative zum DHTML-Webserver-Paradigma.
Auch bei anderen innovativen Firmen wie Microsoft, Adobe, openSource.XUL sehe ich hochinteressante Ansätze im Kontext von weg-von-dhtml-schlauere-clients. Dazu vermutlich auch später mehr.  

Gruß Axel

[Marinero Atlántico]

Habe was sehr schlau aussehendes über RichClient Platform im Internet gefunden:

Immer auch bedenken, dass Lotus Workbench darauf beruht (auf RCP-Full)

(von http://www.coconut-palm-software.com/the_visual_editor/2004/07/23#when_rcp , hervorhebungen ich. Kursiv=kommentar von mir)
When should one code in Eclipse RCP? When should one choose naked SWT? And when should one choose RCPLite, the new middle-ground?
[...]
RCP

+ Provides higher-level application framework than SWT; more
productive if you need its features and like (& can accept) its
general design approach.

+ Can include Eclipse's update manager if you need to supply software
updates dynamically to clients.  This alone could be RCP's killer app
if you're a corporate developer.
Die Tatsache, dass keine Kosten bei der Verteilung/Update der Clients anfiehl war überhaupt ein sehr, sehr wichtiges Argument für das Entstehen der Web-Intranets

+ If your application's UI has to scale to huge, epic sizes (like
Eclipse's UI has to be able to scale), RCP helps a lot.

- For small to medium-sized applications that aren't updated often or
are client-side-only, RCP is large, heavyweight, and slow.  All that
dynamic UI stuff that helps so much if your UI has to scale to large
numbers of features can just get in the way if you have small and
simple requirements.


SWT (by itself)

+ Small, lightweight, performant.

+ Is low-level.  You can code almost anything in it.

- Is low-level.  Although you can code almost anything in it, it's so
low-level it sometimes feels like you have to code everything in it.


There's a third option not being talked about much, and that is the
SWTworkbench RCPLite framework.  RCPLite is intended to sit in the
middle-ground between naked SWT and Eclipse's full-blown RCP.  Here's
roughly how it stacks up:

RCPLite (http://www.swtworkbench.com/devzone/rcplite/index.shtml):

+ Small, lightweight, performant.  It's designed to be as thin a layer
as possible on top of SWT and still provide application framework
features.

+ Imitates the best features of Eclipse's UI and programming model and
improves on a few of them.  Most notably these include perspectives, a
unified view/editor model, and the Action framework (for menu bar and
tool bar management).

+ Retains Eclipse 2.1's native look & feel.

+ A much simpler programming model than Eclipse's.

- What you gain in simplicity you lose in UI scalability.  RCPLite
isn't designed to be able to support as many features in the
application UI as Eclipse can (yet it's designed to support a
reasonable-sized app; for example, one could rewrite Quicken(tm) using
it just fine).

- No update manager for RCPLite (yet).


Werde RCPLite versuchen. Kein Bedarf den Helden zu spielen

Gruß Axel