- Die Container und Layout-API sehen ein wenig anders aus. Bei SmartGWT gibt es eine Klasse Layout (und Unterklassen wie VLayout), die eigentlich Container mit einem speziellen assoziierten Layoutmechanismus sind. So heißt es dann auch layout.addMember(…) und das ist gewöhnungsbedürftig. Da gefällt mir Ext-GWT besser, wo wie bei AWT/Swing den Layout-Manager auf einem Container setzt. Hier wird also bei Ext-GWT das übliche Strategie-Muster eingesetzt.
- Die Optik von Ext-GWT (etwa bei Menüs) ist in meinen Augen deutlich besser. Es gibt viele kleine Fehler in der Darstellung, etwa Ein-Pixel freie Linien.
- Ext-GWT bietet bessere Unterstützung für Formulare, was etwa das automatische Ein-/Ausfalten von Details angeht.
- SmartGWT bietet vertikale Tabs und eine Integration vom Google Kalander.
- Das Binding funktioniert bei beiden völlig anders. SmartGWT erwartet spezielle Binding-Komponenten, also etwa DataSourceTextField statt TextItem (ja, warum das nun nicht DataSourceTextItem heißt, ….). Wenn später Quellcode umbaut wird, muss man die Komponenten ändern und wenn eine angepasste Unterklasse etwa von TextItem erbt, muss das auch anpasst werde. Das Design ist in meinen Augen nicht optimal. Besser macht es Ext-GW; hier bleibt man bei den Standardkomponenten und setzt diese später zu einer Gruppe (FormBinding) zusammen.
- Ext-GWT bietet eine prima XTemplate-Klasse, in der dann Platzhalter definiert werden können, etwa {[new Number(values.change).toFixed(2)]}, die später über das Binding ersetzt werden.
- Bei SmartGWT lässt sich nicht jede Komponente in einen DynamicForm setzen. Bei der RTF-Komponente RichTextEditor (ein VLayout) geht das zum Beispiel nicht. Dafür gibt es noch mal den Wrapper RichTextItem (ein FormItem). Das ist verwirrend.
- Ohne Anpassungen beim SmartGWT ist der Font rechts einer Checkbox ein andere als Links von einem Textfeld.Und Warum muss bei TextItem immer standardmäßig ein Doppelpunkt gesetzt werden, was dann auch noch mit einem Leerzeichen vom Text abgesetzt wird?
- SmartGWT hat merkwürdige Klassennamen wie com.smartgwt.client.core.BaseClass oder IButton (und eine Button-Klasse gibt es auch noch).
- SmartGWT-Methoden mit den Namen addItem(), addMember(), addChild() und addPeer() tragen nicht zur Übersichtlichkeit beim Hinzufügen von Komponenten be
Fazit von einer Std. spielen und API-blättern: Ext-GWT erscheint mit vom Design durchdachter und professioneller. Die SmartGWT API wirkt an vielen Stellen unverständlich und überfachtet. Ein Beispiel:
- void setAttribute(java.lang.String attribute, boolean value)
- void setAttribute(java.lang.String attribute, java.lang.Boolean value)
- void setAttribute(java.lang.String attribute, DataClass value)
- void setAttribute(java.lang.String attribute, DataClass[] value)
- void setAttribute(java.lang.String attribute, java.util.Date value)
- void setAttribute(java.lang.String attribute, double value)
- void setAttribute(java.lang.String attribute, int value)
- void setAttribute(java.lang.String attribute, int[] value)
- void setAttribute(java.lang.String attribute, com.google.gwt.core.client.JavaScriptObject value)
- void setAttribute(java.lang.String attribute, java.util.Map value)
- void setAttribute(java.lang.String attribute, java.lang.String value)
- void setAttribute(java.lang.String attribute, java.lang.String[] value)
- void setAttribute(java.lang.String attribute, ValueEnum[] value)
Mit Ext-GWT macht mir die Entwicklung mehr Spaß. Bei der API sind auch viel weniger Klassen/Schnittstellen im Spiel, obwohl die API viel älter ist.