was haltet ihr von rap?

[rap]

rap

lohnt es sich noch icefaces mit jsf etc zu benutzen?

da scheint man ja wirklich alles geboten zu bekommen

wie seht ihr das?

 

[foobar]

RAP sieht interessant aus, aber solange das Ding nicht stable ist und von anderen Leuten ebreits eingesetzt wird würde ich nicht daruaf setzen.
Es gibt auch noch jede Menge Alternativen dazu z.b. GWT oder qooxdoo ohne RAP.

 

[HLX]

Sehe ich genauso. Mich stört außerdem, dass man sich an Eclipse und die Plugin-Technologie bindet. Da ist man z.B. mit GWT freier.

 

[byte]

In den meisten Fällen bindet man sich an irgendwas, im Falle von GWT z.B. an den (nicht offenen) GWT-Compiler.

Ich denke, dass OSGi / Equinox in Zukunft noch deutlich an Bedeutung zulegen wird. Es ist einfach ein geniales Konzept, dass von Anfang an Bestandteil von Java hätte sein müssen, auch wenn noch nicht alles in Eclipse Equinox sauber umgesetzt ist.

 

[Niki]

Hat jemand eigentlich schon mit zk größere Projekte umgesetzt?
Ich hab eine RIA Anwendung mit Thinwire realisiert, dieses Framework wird aber nicht mehr weiter entwickelt. Als Alternative kommt jetzt wahrscheinlich zk in Frage.
Was haltet ihr davon?

 

[foobar]

Ich denke, dass OSGi / Equinox in Zukunft noch deutlich an Bedeutung zulegen wird. Es ist einfach ein geniales Konzept, dass von Anfang an Bestandteil von Java hätte sein müssen, auch wenn noch nicht alles in Eclipse Equinox sauber umgesetzt ist.

Das denke ich auch. E4 zielt ja auch genau in die Richtung Equinox auf Serverseite.

Im Moment gibt es jede Menge Technologien auf dem RIA Markt. Die Zukunft wird zeigen wer sich dort durchsetzen kann. Bin mal gespannt wie sich JavaFx so schlägt bzw. ob sich sowas auch für Businessapps nutzen lässt. Die Beispiele die ich bisher gesehen habe waren alle Klickibunti.

 

[robertpic71]

Ich hatte RAP relativ lange auf meiner Liste, allerdings kam es während meiner Evaluierungsphase nicht zu einem Release, ganz abgesehen von Doku und Tuturials. Soweit ich das Überblicke, bringt RAP darfür gleich von Anfang an, einen GUI-Builder mit.

Generell zur Frage JSF+Ajax vs. Ajax-Framework: JSF + Ajaxzusatz macht für mich vielleicht noch Sinn, wenn ich JSF-Anwendungen und Wissen habe. Eine Hürde mehr fällt bei JSF eh nicht mehr auf....
Was noch für JSF sprechen könnte, ist die (angeblich) gut Netbeansuntersützung (Visual JSF). Nachdem ich an Eclipse/Websphere gebunden bin, habe ich mir das allerdings nicht angesehen.

Von Null weg werden wohl die meisten Ajaxframeworks weniger Code wie eine JSF-Ajaxanwendung produzieren.

Hat jemand eigentlich schon mit zk größere Projekte umgesetzt?
...Was haltet ihr davon?

Mit einem großen Projekt kann ich nicht dienen, aber mit einem Fallbeispiel, eines kleineren Projektes:

Meine Webvorkenntnisse: gegen 0, kein Html, kein JSP, nur eine HelloWorld Servlet
Vorträge/Schulungen: 1 Tag bei IBM für einen Überblick der Technolgien (Servlet, JSP, JSF, Struts)

Schulungsvorschlug: Servlet, JSP, JSF --> erste Ergebnisse nach ca. 1/2 Jahr (wird auch so im Forum vorgeschlagen)

Nach etwas mehr als einer Woche (trotz 12 Stundentag, ca. 4 Stunden/Tag) herumspielen mit ZK (mit Vergleichen mit GWT und JSF) habe ich mich an den Prototypen meines Onlinekataloges gewagt.

Nach einer 8-Stunden Nachschicht war der Prototyp fertig (dynamisch nachladender Tree, Daten aus einer Access-DB).
Ein paar Tage später und viele Features mehr, wurde die Entscheidung getroffen, diesen Katalog auch den Kunden zugänglich zu machen, da er besser als die Katalog-CD zu bedienen waren.

Bis zur kompletten Fertigstellung (inkl. Integration eines gekauften Webshops) sind ca. 30 Arbeitstage (a 8 h) in die Entwicklung geflossen, wobei davon ca. 45% für das UpdateManagment (inkl. WebCMS für Korrekturen, Konvertierprogramme, Linkfinder) abfielen.

[EDIT/NACHTRAG]Hier der Katalog zum Anschauen: OdKatalog

Ausschlaggebend (neben dem einfachen Einstieg) für ZK war aber eigentlich die Möglichkeit der Tastatursteuerung (wir haben jetzt nocht sehr viele GreenScreen-Anwendungen), das Desktopfeeling der Anwendungen und der Erstellung sowie das Databinding. Sachen wie Prompter, dürfen einfach keine Arbeit machen und das geht sehr elegant:

Combobox füllen (Spring als Variablenresolver):

<combobox id="color">
<comboitem label="${each.name}" value="${each}"
forEach="${colorManager.getAll()}" /> </combobox>

Comboxbox füllen (mit JDBC-Binding, ohne Domainclasses)

<label value="Status:"/>
<combobox id="status">
<comboitem label="${each.name}" value="${each}"
	forEach="${JDBC1.getSQL('select * from statuses')}" />
</combobox>

Wenn du lieber ohne GUI-Beschreibung (nur mit Java) arbeitest, besteht die GUI nur aus einer Zeile:

your.zul =

<window id="root" use="package.YouClass"/>

Java =

public YourClass extends Window {

  public void onCreate() {
      this.appendChild(new Label("Hello World");
     // GUI-Komponenten anlege, EventHandler anmelden
  }
  
}

vs.

<window id="root">
    <label value="Hello World"/>
</window>

Ich will hier nicht alles gnadenlos zutexten, ich habe noch zahlreiche Codebeispiele und ein paar Erfahrungswerte (Memory..). Also nur melden, wenn du noch Infos brauchst.

/Robert

 

[Niki]

Ja, danke mal für die Info. Ich hab mich jetzt eh schon recht weit in zk eingearbeitet. Es ging mir eigentlich nur um Erfahrungsberichte und deiner stärkt meine Überzeugung dieses Framework einzusetzen.
Ich bin nach ca. 2 Tagen zu tollen Ergebnissen gekommen.
Ich würde nur eines gerne wissen.
1) Wie realisier ich es, die Start-Argumente in die Applikation einzulesen, brauch ich dafür wirklich das SessionInit Interface? oder geht das direkt im zul File auch?

2) Ich habe ein Bean, welches meine BL enthält. Die Daten von diesem Bean werden über die ganze Applikation gesammelt und am Ende wird gespeichert. Ist es da am besten das Bean in die Session zu stellen oder gibt es da andere Lösungen?

3) Ich habe für jede Maske ein zul-File. Im zscript Tag erzeuge ich mir für jede Maske ein Controller Objekt und einen PropertyChangeListener, welchen ich beim Controller registrier. Der Controller reagiert z.B. auf Button-Klicks, mach was in der DB und wirft zum aktualisieren der GUI PropertyChangeEvents. Ist das eine saubere Lösung oder gibt es da auch elegantere Wege?

Danke schon mal für die Tipps!

 

[byte]

Hier der Katalog zum Anschauen: OdKatalog

Folgende Punkte gefallen mir nicht an dem Katalog:

- Der Baum passt sich nicht an die Größe des Browsers an
- Die Knoten im Baum haben kein + Icon (erst wenn man einmal drauf klickt und wieder schließt).
- Das Detail Fenster hängt einfach so in der Gegend rum, überlappt sogar den Baum)
- Der Look (ist das ZK-Standard oder hast Du das selbst geschrieben?) sieht nicht wirklich dolle aus.


Nicht böse gemeint, aber Look and Feel (bzw. Software-Ergonomie) finde ich bei der Seite eher mies. Und genau das ist ein Punkt, weswegen man ja RIA macht.

Da sehen andere Sachen imo wesentlich besser aus, z.B. folgende GWT Library (leider mittlerweile nur noch GPL):

http://extjs.com/explorer/#asynctree (Demo des asynchronen Baums)

 

[robertpic71]

Hallo niki:
1.) An die Parameter kommt man auch so ran:

// this = window 
Map parms = this.getDesktop().getExecution().getParameterMap();
// oder 
searchText = this.getDesktop().getExecution().getParameter("text");
// im zscript
desktop.getExc..

2.) Das kann man natürlich über die Session machen. Zusätzlich gibt es noch die Möglichkeit den Bean im Desktop als Attribut zu speichern (get/setAttribute(name, Object). Der Desktop hat den Vorteil gegenüber der Session, dass man sich keine Sorgen machen muss, was passiert wenn der Benutzer mit Tabs im Browser gleichzeitig arbeitet.

3.) Ich arbeite eigentlich sehr "Eventarm" mit Databinding, welches sich um die Synchronisation zwischen UI und Daten kümmert. Ein paar Annotationbeispiele findest du >> hier <<. Für die Buttons nutze ich meist das Forward-Attribute.
[EDIT: Link korrigiert]

@byto:

- Die Knoten im Baum haben kein + Icon (erst wenn man einmal drauf klickt und wieder schließt).

Das war Absicht so und eher ein Mehraufwand. Ich habe mich die an der CD-Vorlage orientiert.

- Das Detail Fenster hängt einfach so in der Gegend rum, überlappt sogar den Baum)

Die Erstausgabe ist optimiert auf 1024x768, da geht es nicht ohne Überlappung. Man kann das Fenster ja herumschieben(*)

- Der Baum passt sich nicht an die Größe des Browsers an
- Die Knoten im Baum haben kein + Icon (erst wenn man einmal drauf klickt und wieder schließt).
- Das Detail Fenster hängt einfach so in der Gegend rum, überlappt sogar den Baum)
- Der Look (ist das ZK-Standard oder hast Du das selbst geschrieben?) sieht nicht wirklich dolle aus.

- Der Look (ist das ZK-Standard oder hast Du das selbst geschrieben?) sieht nicht wirklich dolle aus.

Der Look ist weitgehend ZK-Standard, ich habe nur für Farben überschrieben. Bei den Farben habe ich mich
an die Firmenfarben gehalten, welche nicht gerade ein Vorteil. Was den Look angeht, ist ZK etwas im
Hintertreffen. Entweder man beschäftigt sich mit CSS oder wartet einfach noch etwas ab (schon die nächste
Version hat dann annäherend ExtJS-Optik). Wobei die Optik bei meiner Auswahl kaum eine Rolle gespielt hat.

- Der Baum passt sich nicht an die Größe des Browsers an

+ *)
Das Design ist noch weitgehend ZK Version 2.1 mit dem Wissenstand nach 3 Wochen ab 0=Webkenntnissen.
Zum damligen Zeitpunkt wäre nur ein Auswerten des onClientInfo möglich gewesen, welches mir die Browsergröße zurückliefert. Mittlerweile kann ich zwischen dem ExtJS und ZK-Layoutmanager wählen, welche mir den Platz optimal ausnutzen.

Leider bekomme ich für den Katalog überhaupt keine Zeit abgestellt (Katalog ist ein Service, kein Kerngeschäft). Bis auf den Look würden sich deine Kritikpunkte in einigen Stunden ausbügeln lassen. Da der Katalog aber mehr als die CD oder den dazuerhältichen Webkatalog (für 30.000 Euro + Installation..) kann, ist bei uns jeder glücklich.

Verbessern kann man immer, aber der Link war eher unter dem Gesichtspunkt was man als Webanfänger in paar Wochen mit ZK auf die Reihe bringt gedacht.

/Robert

 

[Niki]

Super! Besten Dank. Werd mir das mal mit den DataBindings anschaun

 

[robertpic71]

@Niki
Bitte schön, bei Fragen einfach posten.

@byto
Nur weil die mein Katalog nicht gefällt, ist das Programmier-Werkzeug nicht unbedingt schlecht. Allerdings werde ich mir die eine oder andere Anregung daraus mitnehmen...

Was mich an GWT stört, ist dieser "Modeloverhead". Um bei dem Treebeispiel zu bleiben. Da gibt es 4(! + 2 Interfaces) Klassen mit insgesamt ca. 150 Zeilen Code. Viele davon müssen ein GWT-Model implementieren. Bei ZK kann ich in vielen Fällen direkt den JPA/Hibernate/JDBC/Webservice/Spring..-Output übernehmen.
Wenn ich noch zuviel Zeit im Urlaub habe, baue ich es mit ZK nach - grob geschätzt, benötige maximal 50% an Code/Codezeilen im Vergleich zur GWT-Lösung. So nebenbei stellen die RPC-Dienste auch ein Sicherheitsrisiko (nicht unbedingt im Intranet) dar.

Ein paar Vergleichsbeispiele gibt es >> hier <<. Wobei man bei den ZK-Beispielen eigentlich 1 File + 10 Zeile für MVC dazurechnen müsste.

Auch das Umdenken zwischen Client/Serverdenken fällt bei ZK flach. Man braucht sich nur >> diesen Thread << anzusehen. Von dieser Art der Problemen (was läuft am Client) ist man bei ZK total entbunden.

In ZK kann ich auch durchgehend UI- und Modelcode debuggen.

Auch wenn andere Frameworks schöner "blinken", ZK war das einzige Ajaxframework, welches gleich auf der Demoseite meine Anforderungen (Hibernate und JDBC-Anbindung, Cursorsteuerung, Tastaturabfragen) behandelte.

Um jetzt wieder auf den eigentlichen Thread zurückkommen: RAP wird sicher viele dieser Vorteile mitbringen, ist aber wie schon gesagt, spät dran.

/Robert

 

[byte]

Nur weil die mein Katalog nicht gefällt, ist das Programmier-Werkzeug nicht unbedingt schlecht.

Das habe ich doch auch nicht gesagt.

Was mich an GWT stört, ist dieser "Modeloverhead".

Jo, es gefällt mir auch nicht, dass man DTOs an den Client weiterreichen muss. Aber es gibt Libraries, die einem das Assembling abnehmen, so dass der Programmieraufwand minimiert ist.

Um bei dem Treebeispiel zu bleiben. Da gibt es 4(! + 2 Interfaces) Klassen mit insgesamt ca. 150 Zeilen Code. Viele davon müssen ein GWT-Model implementieren. Bei ZK kann ich in vielen Fällen direkt den JPA/Hibernate/JDBC/Webservice/Spring..-Output übernehmen.

Du musst nur Interfaces im Modell implementieren, wenn Du Databinding benutzen willst, also die GUI-Elemente an Deine Beans binden willst. Willst Du das nicht haben, brauchst Du das aber nicht nutzen.
Die Implementierung funktioniert halt analog zu Richclient-Frameworks wie SWT oder Swing. Wenn man das kann, dann kann man auch GWT / GXT. Bei ZK schreibe ich komische XML-Dateien wie bei JSP - mag ich (persönlich) gar nicht.

So nebenbei stellen die RPC-Dienste auch ein Sicherheitsrisiko (nicht unbedingt im Intranet) dar.

Das ist kein spezielles GWT-Problem. Das hast Du bei allen Systemen, die Services nach aussen anbieten.

Auch das Umdenken zwischen Client/Serverdenken fällt bei ZK flach. Man braucht sich nur >> diesen Thread << anzusehen. Von dieser Art der Problemen (was läuft am Client) ist man bei ZK total entbunden.

Kann man genauso gut als Einschränkung sehen, dass alles auf dem Server läuft.

In ZK kann ich auch durchgehend UI- und Modelcode debuggen.

Genauso in GWT.

Auch wenn andere Frameworks schöner "blinken", ZK war das einzige Ajaxframework, welches gleich auf der Demoseite meine Anforderungen (Hibernate und JDBC-Anbindung, Cursorsteuerung, Tastaturabfragen) behandelte.

Für mich ist grade Look and Feel und Software-Ergonomie der wichtigste Punkt bei RIA. Sonst kann ich die Seite auch gleich mit konservativen Request-Response Technologien a la JSF und Co. bauen.

Um jetzt wieder auf den eigentlichen Thread zurückkommen: RAP wird sicher viele dieser Vorteile mitbringen, ist aber wie schon gesagt, spät dran.

Ich weiss nicht, obs spät dran ist. IMO stecken alle RIA Technologien noch in den Kinderschuhen. Es gibt viele Webframeworks und atm hat keins wirklich die Nase vorne. Wenn RAP irgendwann stable ist und das hält, was es verspricht, dann könnte es durchaus einschlagen! Zumal es schon maßig SWT-Entwickler gibt, die Ihr Knowhow dann mitnehmen können!

 

[robertpic71]

Was mich an GWT stört, ist dieser "Modeloverhead".

Jo, es gefällt mir auch nicht, dass man DTOs an den Client weiterreichen muss. Aber es gibt Libraries, die einem das Assembling abnehmen, so dass der Programmieraufwand minimiert ist...
Du musst nur Interfaces im Modell implementieren, wenn Du Databinding benutzen willst, also die GUI-Elemente an Deine Beans binden willst. Willst Du das nicht haben, brauchst Du das aber nicht nutzen....
[/quote]
Ohne Databindung gibt es halt in der mehr Code im GUI-Teil. Das sehr mächtige Databinding mit leicht erweiterbaren Convertern ist mMn der größte Vorteil von ZK. Man findet fast immer einen Weg seine bestehende Models (ohne Änderung) weiterzuverwenden. Auch der Einsteiger wird sich mit ZK leichter tun: keine Proxies, keine Libareis zum Assembling, einfach die Modeldaten nehmen so arbeiten wie er es gewohnt ist: komplette mit Javacode, mit einem GUI-Model ala Swing/SWT/GWT oder dem annotation Databinding (ala JSF) - je nachdem aus welcher Ecke (Swing, JSP, JSF) er kommt.

Die Implementierung funktioniert halt analog zu Richclient-Frameworks wie SWT oder Swing. Wenn man das kann, dann kann man auch GWT / GXT. Bei ZK schreibe ich komische XML-Dateien wie bei JSP - mag ich (persönlich) gar nicht.

zu können und wollen: ich kann auch in ZK ein Model ala Swing verwenden, ich will aber lieber gleich den DAO-Output (z.B. Hibernate) als Model verwenden.

Zum XML: Wie schon oben geschrieben: Wer keine GUI-XML's mag braucht nur eine Zeile:
<window id="root" use="package.javaclass"/>
Der Rest läuft dann über Java wie bei Swing/SWT/GWT.

...Umdenken zwischen Client/Serverdenken fällt bei ZK flach...
Kann man genauso gut als Einschränkung sehen, dass alles auf dem Server läuft.

Technisch gesehen, hat jedes System seine Vor- und Nachteile. Schulungstechnisch gesehen ist das ZK-Model leichter zu erlernen.

In ZK kann ich auch durchgehend UI- und Modelcode debuggen.

Genauso in GWT.

Für mich ist grade Look and Feel und Software-Ergonomie der wichtigste Punkt bei RIA.

Hier liegt ZK sicher noch hinter der Konkurrenz, wobei sie genau diesen Punkt mit dem nächsten Release beheben wollen. Mein, mit einer frühen ZK-Version und mit jungen Wissen erstellter Katalog ist da vielleicht kein Paradebeispiel, zumal ich einige Kompromisse wg. dem Katalogmatrial (Tree: bis zu 5 Ebenen mit langen Texten, Seiten: teilweise mit Übebreite, Firmenfarben) eingehen musste. Wobei ich meine, die üblichen Schwachstellen von Ajaxanwendungen (keine Historie --> kein Vor- und zurück, kein Bookmark) vermieden zu haben.

Hier ein Demo einer gestylteren ZK Anwendung: easitdemo.swf

...
Ich weiss nicht, obs spät dran ist... Wenn RAP irgendwann stable ist und das hält, was es verspricht, dann könnte es durchaus einschlagen! ...

Leider ist es halt wieder ein Beispiel für die Splittung der Javagemeinde. Auch wenn RAP seinen Weg macht, gibt es viele Alternativen und ein Java-Ajax-Programmierer != anderen Java-Ajax-Programmier (weil anderes Framework). Da hat so manche Monopollösung einen Vorteil.

/Robert

 

[byte]

Leider ist es halt wieder ein Beispiel für die Splittung der Javagemeinde. Auch wenn RAP seinen Weg macht, gibt es viele Alternativen und ein Java-Ajax-Programmierer != anderen Java-Ajax-Programmier (weil anderes Framework). Da hat so manche Monopollösung einen Vorteil.

Naja, was heisst Splittung der Java-Gemeinde? Mich persönlich würde ich weder als Java-Programmier noch als AJAX-Programmierer betiteln. Ich bin Informatiker (im Arbeitsvertrag steht Systemanalytiker). Java ist bloß ein Werkzeug für mich, ebenso wie die vielen Libs und Frameworks, mit denen ich bisher Erfahrungen sammeln konnte.
Gäbe es nur ein Framework, wäre es schon langweilig. So ist halt jeder Experte auf seinem Gebiet.

 

[robertpic71]

[quote="byto"...Mich persönlich würde ich weder als Java-Programmier noch als AJAX-Programmierer betiteln. Ich bin Informatiker (im Arbeitsvertrag steht Systemanalytiker). Java ist bloß ein Werkzeug für mich, ebenso wie die vielen Libs und Frameworks, mit denen ich bisher Erfahrungen sammeln konnte.
Gäbe es nur ein Framework, wäre es schon langweilig. So ist halt jeder Experte auf seinem Gebiet.[/quote]

Mir geht es weniger um die Betitelung, sondern eher um den Werkzeug/Framework-Überschuß. Das macht die Entscheidung nicht gerade leichter. Auch was die Hilfestellung in Foren angeht: Durch die Vielzahl der Ajaxlösungen, bleibt so mancher Fragesteller auf der Strecke. Ein RAP zu einem früheren Zeitpunkt hätte die Ajaxframeworkwahl vielleicht erleichtert...

BTW: Ein Lob für eine vielen GWT-Antworten hier im Forum :toll: (soviel Fragen hatte ich zu ZK noch nicht )

/Robert

 

[HLX]

Habe mir nun ZK auch mal etwas näher angesehen.

Im Vergleich von ZK und GWT stelle ich fest, dass beide Frameworks unterschiedliche Ansätze verfolgen. ZK setzt den Entwickler in den Vordergrund und versucht ihm die Arbeit bei der Erstellung von AJAX-Anwendungen zu erleichtern. (So wirkt es zumindest auf der Homepage).

GWT hingegen geht auf bestimmte Problematiken des Web ein und passt die Entwicklung den dadurch entstehenden Erfordernissen an. GWT rendert die GUI bewusst beim Client um a) die Antwortzeiten zu minimieren, b) die Client-/Server-Kommunikation zu minimieren, c) die Serverlast zu minimieren. Wenn man in GWT z.B. einen Baum aufklappt erhält man eine sofortige Reaktion, was dem Desktop-Feeling sehr nahe kommt.

Die teilweise Verarbeitung auf dem Client geht leider nur über eine gewisse Trennung, da Javascript nunmal etwas einfacher gestrickt ist (Stichwort Typisierung). Datenhaltung auf dem Client erfordert außerdem Objekte die Serialisierbar sind. Unter Berücksichtigung ddieser Umstände wurde bei GWT bislang ganze Arbeit geleistet. Leider ist es natürlich nicht ganz so simpel geworden, wie bei ZK - wir sind allerdings auch nicht im Wunschkonzert. Wenn der Kunde einen Ferrari will, dann kann ich ihm keinen Opel vor die Nase setzen, mit der Begründung der wäre aber einfacher zu entwickeln gewesen.

Interessant ist, dass ZK mit besserer Sicherheit wirbt, weil der Code auf dem Server ausgeführt wird.
Das erfordert jedoch die Berücksichtigung von Sicherheitsrichtlinien. Wenn Code auf dem Server ausgeführt wird, bzw. der Anwendungszustand oder der Zustand einer Benutzersitzung auf dem Server, also einer "öffentlichen" Maschine gehalten wird, ist er potentiell angreifbar.

[Edit] (ein Vergleich mit RAP war mir leider nicht möglich, da ich das Framework nur sehr oberflächlich kenne)

 

[byte]

Die teilweise Verarbeitung auf dem Client geht leider nur über eine gewisse Trennung, da Javascript nunmal etwas einfacher gestrickt ist (Stichwort Typisierung). Datenhaltung auf dem Client erfordert außerdem Objekte die Serialisierbar sind. Unter Berücksichtigung ddieser Umstände wurde bei GWT bislang ganze Arbeit geleistet. Leider ist es natürlich nicht ganz so simpel geworden, wie bei ZK.

Also nach zwei GWT-Projekten muss ich sagen, dass ich GWT für sehr einsteigerfreundlich halte. Natürlich hat man bei GWT immer die strikte Trennung zwischen Client und Server, aber das sehe ich nicht als Nachteil. Im Gegenteil: in größeren Projekten ist das durchaus vorteilhaft. Die Arbeit lässt sich leichter auf die Entwickler aufteilen. Team A arbeitet am Client, Team B am Server. Ist die Schnittstelle zwischen beiden Layern definiert, kann jedes Team völlig unabhängig und parallel arbeiten, ohne sich in die Quere zu kommen.
Meiner Meinung nach macht eine solche Schichtentrennung ein Projekt nicht komplizierter sondern einfacher!

 

[robertpic71]

Hallo HLX

Im Großen und Ganzen kann ich deinen Ausführungen zustimmen, noch 3 Ergänzungen:

Wenn der Kunde einen Ferrari will, dann kann ich ihm keinen Opel vor die Nase setzen, mit der Begründung der wäre aber einfacher zu entwickeln gewesen.

Ich sehe den Hauptseinsatz von ZK im Intranet für Applikationen. Die Anforderungen an den Server sind ähnlich einer JSF-Anwendung. Bei den Pflichtenheften die ich bekomme, geht es meistens um die Funktionen und bis wann es fertig sein kann. Die Performance wird - wenn überhaupt - mit ein paar Obergrenzen abgehandelt.

Wenn man in GWT z.B. einen Baum aufklappt erhält man eine sofortige Reaktion

Wenn ich den dynamsichen Baum von GWT mit meinem Katalog vergleiche, kommt mir mein Katalog nicht langsamer vor, obwohl ich noch die HTML-Daten für die Katalogseite laden muss. Ein statischer Baum wird auch bei ZK als ganzes an den Client übetragen und öffnet sich genauso schnell.

Insgesamt nehme ich die etwas langsameren (im Intranet kaum wahrnehmbaren) Reaktionszeiten für weniger Code in Kauf. RAP verfolgt übrigens genauso den serverseitigen Ansatz.

Interessant ist, dass ZK mit besserer Sicherheit wirbt, weil der Code auf dem Server ausgeführt wird.
Das erfordert jedoch die Berücksichtigung von Sicherheitsrichtlinien. Wenn Code auf dem Server ausgeführt wird, bzw. der Anwendungszustand oder der Zustand einer Benutzersitzung auf dem Server, also einer "öffentlichen" Maschine gehalten wird, ist er potentiell angreifbar.

Was den Servercode angeht, ist es bei ZK gleich wie bei JSP, JSF usw.
Der Sicherheitsvorteil ist eher gegenüber den clientseitigen Ajaxlösungen bezogen: Diese müssen die Daten via RPC oder ähnlichem bereitstellen - wie man darauf zugreift kann via Javascript-Debugger ermittelt werden.

Bei ZK werden GUI-Komponenten gesynct. Selbst die im Viewer definierten Prüfungen werden erst beim Zurücksyncen am Server geprüft. Ich kann mir relativ sicher sein, dass selbst verändertes Javascript keine falschen Daten anzapfen kann.

..dass ich GWT für sehr einsteigerfreundlich halte. ..

GWT ist sicher auf wesentlich einsteigerfreundlicher als z.B. JSF, Struts&Co. Ich stufe halt ZK noch einfacher ein. Vor allem Ein- und Umsteiger tun sich sicher leichter.

Meiner Meinung nach macht eine solche Schichtentrennung ein Projekt nicht komplizierter sondern einfacher!

Bei GWT ist die Schichtentrennung halt "erzwungen", aber es hindert einen ja keiner Interfaces für das Modell zu definieren und auch ohne "Zwang" zu trennen.

[Spekuliermodus an:]
Obwohl GWT sicher ein paar unbestrittene Vorteile hat, werden sich im Applikations/J2EE-Bereich die serverseitigen Lösungen (RAP, JSF-Komponenten mit Ajaxfunkt., ZK?) durchsetzen bzw. viele Client-Ajax-Lösungen als Serverkomponente eingebunden sein - wie jetzt schon bei ZK: FCKEditor, Yui-Ext, GoogleMaps...
[Spekuliermodus aus:]

/Robert

 

[HLX]

Also nach zwei GWT-Projekten muss ich sagen, dass ich GWT für sehr einsteigerfreundlich halte!

Mit GWT selbst habe ich die gleiche Erfahrung gemacht, allerdings hörte die Freude bei Ext-GWT ganz schnell auf. Da wurden mit der Übernahme von MyGWT einfach grundlegende Dinge geändert, ohne diese angemessen zu dokumentieren. Bis zum ersten RC war Ext GWT eine Katastrophe. Ich denke allerdings, dass sie insgesamt auf dem richtigen Weg sind. (...abgesehen vom Lizenzmodell --> GPL :wink: )

[Spekuliermodus an:]
Obwohl GWT sicher ein paar unbestrittene Vorteile hat, werden sich im Applikations/J2EE-Bereich die serverseitigen Lösungen (RAP, JSF-Komponenten mit Ajaxfunkt., ZK?) durchsetzen bzw. viele Client-Ajax-Lösungen als Serverkomponente eingebunden sein - wie jetzt schon bei ZK: FCKEditor, Yui-Ext, GoogleMaps...
[Spekuliermodus aus:]

Ich denke, es ist im Moment noch zu früh um sagen zu können, welche Technologie ihren Weg machen wird. Die AJAX-Frameworks sind alle noch recht jung. Sie werden sich noch erheblich weiterentwickeln. In ein paar Jahren wird sich dann wohl eine Richtung ergeben.

Und selbst dann hängt es noch davon ab, wer seine Finger im Spiel hat. Struts z.B. war lange Zeit für viele die erste Wahl als Web Framework. Dann wurde JSF von SUN zum Standard erklärt und schon drehte sich der Wind. Anderes Beispiel: wer hätte vor einem Jahr gedacht, dass man Sorgen um die kostenlose Library GWT-EXT haben müsste. Nun ist EXT-JS (die Basis der Bibliothek) - GPL...

 

[byte]

Mit GWT selbst habe ich die gleiche Erfahrung gemacht, allerdings hörte die Freude bei Ext-GWT ganz schnell auf. Da wurden mit der Übernahme von MyGWT einfach grundlegende Dinge geändert, ohne diese angemessen zu dokumentieren. Bis zum ersten RC war Ext GWT eine Katastrophe. Ich denke allerdings, dass sie insgesamt auf dem richtigen Weg sind. (...abgesehen vom Lizenzmodell --> GPL :wink: )

Ext-GWT ist / war doch ein Wrapper für Ext JS - also kein reines GWT. Da habe ich gleich die Finger von gelassen.
Oder redest Du von (ehemals MyGWT, heute) GXT? Das habe ich nicht mehr benutzt, seit es zu dem Ext JS Verein gewechselt und nicht mehr in der LGPL Lizenz verfügbar ist.

 

[HLX]

Mit GWT selbst habe ich die gleiche Erfahrung gemacht, allerdings hörte die Freude bei Ext-GWT ganz schnell auf. Da wurden mit der Übernahme von MyGWT einfach grundlegende Dinge geändert, ohne diese angemessen zu dokumentieren. Bis zum ersten RC war Ext GWT eine Katastrophe. Ich denke allerdings, dass sie insgesamt auf dem richtigen Weg sind. (...abgesehen vom Lizenzmodell --> GPL :wink: )

Ext-GWT ist / war doch ein Wrapper für Ext JS - also kein reines GWT. Da habe ich gleich die Finger von gelassen.
Oder redest Du von (ehemals MyGWT, heute) GXT? Das habe ich nicht mehr benutzt, seit es zu dem Ext JS Verein gewechselt und nicht mehr in der LGPL Lizenz verfügbar ist.

Ist leicht durcheinander zu bringen:
- GWT-EXT ist ein Wrapper für ExtJS und kann nur noch auf der letzten LGPL-Version von ExtJS weiterentwickelt werden
- mit Ext-GWT meine ich GXT. Habe mir das vor kurzem mal angeschaut - ist mittlerweile eine leistungsfähige Bibliothek mit praktischen Widgets, MVC-Unterstützung und zusätzlichen Features wie TableBinding und Theme-Support. Ich hoffe allerdings, dass es bald eine LGPL-Alternative dazu gibt bzw. dass GWT selbst nochmal ordentlich nachlegt.