Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder ein alternativer Browser verwenden.
Hai,
ich hoffe mein Thema passt in dieses Unterforum. Wenn nicht bitte verschieben.
Ich habe eine ganz allgemeine Frage. Ich möchte eine Anwendung erstellen, welche von jedem beliebigen Standort Daten in einer Datenbank verwaltet. D.h. es öffnet irgenwo ein Bediener eine Internetseite und kann sich an eine DB anmelden und dort Erfassungstätigkeiten durchführen. Das Ganze soll "Mehrplatzfähig" sein. Welche DB sich dahinter verbirgt spielt erstmal keine Rolle. Wenn es geht soll es möglich sein die DB wechseln zu können. Da ich bisher Oberflächen in C++ programmiert habe, möchte ich auch die graphischen Aufbereitungen der Daten aus der DB mit integrieren.
Ich habe mich bisher wenig mit diesen Techniken beschäftigt. Daher möchte ich wissen, welcher generelle Lösungsweg für mich in Frage kommt.
Ich möchte einfach wissen, welche Möglichkeiten es gibt um meine Ursprungsfrage zu beantworten. Sicher ist mir klar, dass es sehr viele Wege gibt, um nach Rom zu kommen. Ich suche halt eine aktuelle, sichere und für einen Starter überschaubare Lösung .
Ich bin gerade dabei mich mit Servlets, JSP, JSF usw. zu beschäftigen. Was mir nicht ganz klar ist, wie ich aus einem Servlet Informationen an einen Browser schicke. Diese sollen neben den eigentlichen Daten auch eine vernünftige Darstellung enthalten. Ich habe gelesen, dass hierfür eine Applet nicht gearde die beste Lösung ist. Kann man denn direkt aus einem Servlet Grafik-Komponenten an den Browser schicken. Ein Beispiel würde mir sicher weiterhelfen.
Damit meine ich die Komponenten, die für die Darstellung der Daten z.B. in einer Tabelle sorgen (keine HTML-Tabelle). Bei einem Applet funktioniert das mit SWING. Ich habe schon ein paar mal den Begriff "Web-Frameworks" gelesen. Hilft mir das ev. weiter?
Frameworks sind meist eine gute Sache, Webframeworks um mit Java eine Web Anwendung zu schreiben sind imho eine Notwendigkeit.
In HTML kann man auch DIVs verwenden statt der üblichen Tabellen, das Ergebnis ist aber fast dasselbe.
Das von dir genannte JSF ist ein solches Framework, und ein sehr komplexes dazu.
Dann kommt noch die Tatsache dazu, dass du, bevor du JSF einsetzen kannst, Servlets und JSPs genau kennen musst, und bevor du das lernst, musst du allerdings ein bisschen was vom HTTP Protokoll verstehen und einiges über HTML, CSS und JavaScript.
Aber Java muss man schon können bevor man sich an Servlets wagt...
Möglichkeiten dein Vorhaben umzusetzen gibt es viele, allerdings kenne ich keine, die ohne fundierte Vorkenntnisse umzusetzen ist, zumindest nicht in Java.
Kenntnisse in den von Dir aufgeführten Sprachen usw. habe ich schon. Ich würde mich nicht als Profi bezeichnen, aber ich komme meistens zurecht. Und ich lerne ja hoffentlich noch dazu .
Vielleicht kannst Du mir doch mal einen Weg aufzeigen, wie Du so etwas lösen würdest. Und wie gesagt, auch ein paar Codes als Beispiele.
Ich bekomme z.B. aus einer DB Daten zurück. Diese möchte ich gerne vernünftig in Tabellenform anzeigen. Aus diesen Daten möchte ich einen zum Bearbeiten auswählen, Änderungen in einer neuen Maske durchführen und diese Änderungen dann zurück in der DB speichern. Also eine GUI.
Für Web-GUIs nutzt man die von mir erwähnten Technologien, dein link wäre auch eine Möglichekit, setzt aber Wissen über JSF voraus, und du weist ja nun was du dafür alles wissen musst
Ich bekomme z.B. aus einer DB Daten zurück. Diese möchte ich gerne vernünftig in Tabellenform anzeigen. Aus diesen Daten möchte ich einen zum Bearbeiten auswählen, Änderungen in einer neuen Maske durchführen und diese Änderungen dann zurück in der DB speichern. Also eine GUI.
Hat zwar nichts mit java zu tun, aber so eine einfache Anwendung würde ich mit Ruby on Rails machen. Geht wirklich sehr einfach und man ist schnell am Ziel.
Wenn du schnell mal eine kleine Webanwendung schreiben möchtest, und dich nicht in Servlets, JSPs, JSF,... einlesen möchtest kannst du auch ein AJAX Framework einsetzen. Ich kann dir da thinwire empfehlen. Das lässt sich sehr ähnlich wie Swing programmieren und ist Event-Gesteuert. Das Tutorial dafür ist auch recht einfach zu verstehen. Wenn du dich dafür entscheidest kann ich dir gerne weiter helfen.
@maki
Welche Frameworks würdest Du mir denn empfehlen und wie greifen die denn über das www auf eine DB zu? Wenn ich von einem Mehrschichten-Architektur ausgehe, wo wird denn das Framework eingesetzt? Bitte Beispiele ....
@tfa
Von Ruby on Rails habe ich bisher kaum etwas gehört. Kann man denn damit die von mir benötigte Zugriffsmöglichkeit realisieren? Was brauche ich denn noch dazu?
@ms
In welcher Form auch immer. Sischer.
@Niki
Ich habe gehört, das AJAX Framework-Technik nicht alle Browser unterstützen. Oder liege ich da falsch?
Wenn ich noch einmal auf die Mehrschichten-Architektur zurück kommen darf. Wenn ich von 4-Schichten ausgehe und die 3. und 4. Schicht mit einem JBoss realisiere, wie erfolgt dann die Rückgabe der Daten zur Präsentationsschicht? Über ein Web-Framework. Und wie binde ich das dann ein.
Ihr merkt schon, so ganz sattelfest bin ich noch nicht
@tfa
Von Ruby on Rails habe ich bisher kaum etwas gehört. Kann man denn damit die von mir benötigte Zugriffsmöglichkeit realisieren? Was brauche ich denn noch dazu?
Du brauchst ein Server auf dem Ruby und Ruby on Rails installiert ist. Zum Entwickeln eine
IDE (ich empfehle Aptana mit RAD-Rails).
Der Nachteil wäre, dass Du Dich erst in Ruby einarbeitet müsstest. Und das unterscheidet sich von
C++ mehr als Java. Außerdem macht Rails einige Vorgaben über Dein Datenmodell z.B. was Primärschlüssel angeht.
Wenn Du die nicht einhalten kannst, kommt Rails nicht in Frage.
Wir sind hier beim Thema JEE und Architektur, einfach mal so einen Überblick geben ist nicht wirklich möglich, viel zu viel.
Du greifst eigentlich nie über das Web auf eine DB zu, sondern auf einen Anwendungsserver.
Ganz kurz:
Tomcat ist ein Servlet Container, hier werden HTML Seiten erzeugt die dann um Client (Browser) geschickt werden, sozusagen die Presentation Tier, welche zum Teil auf dem Server, und zumTeil auf dem Client abläuft.
JBoss ist ein EJB container, hier ist die sog. Business Logik und die Persisten wird auch hier verwaltet, Tomcat kommuniziert über RMI mit dem JBoss. Die Business und Integration Tier sind hier ansässig.
Die DB ist die DB Tier.
Wenn du dich wirklich schon sehr gut mit Java auskennst und dich mit JEE ranhälst, bist du in ca. 1,5-2 Jahren soweit das richtig einzusetzen, ansonsten brauchst du nochmal 2 Jahre, um Java wirklich zu verstehen.
Das sind optimistische Zahlen
Wenn ich noch einmal auf die Mehrschichten-Architektur zurück kommen darf. Wenn ich von 4-Schichten ausgehe und die 3. und 4. Schicht mit einem JBoss realisiere, wie erfolgt dann die Rückgabe der Daten zur Präsentationsschicht?
Wenn du dich wirklich schon sehr gut mit Java auskennst und dich mit JEE ranhälst, bist du in ca. 1,5-2 Jahren soweit das richtig einzusetzen, ansonsten brauchst du nochmal 2 Jahre, um Java wirklich zu verstehen.
Das sind optimistische Zahlen
:toll:
Da Stimme ich voll und ganz zu. Java können und Java können sind zwei paar Schuhe. Die Sprache ist nur mal das Grundgerüst, mitlerweile gibt es aber soviele Frameworks/Technologien dass man schon mal schnell den Überblick verliert.
Ich hab meine Thinwire Applikation im Firefox und im IE getestet und es hat in beidem fast ohne Abweichungen sehr gut geklappt. Schau es dir einfach mal an. Eine kleine Test-Applikation hat man an einem Tag schnell mal geschrieben.
Das mit dem Zugriff auf eine DB über das Web habe ich, glaube ich zumindest, verstanden. Das sieht man ja auch ganz schön an den Schichten-Bildchen.
Genau, der Container schickt HTML-Code. Das ist mir schon klar. Aber wenn ich die Daten dann im Browser ordentlich darstellen will, muss es doch eine möglichkeit geben dies grafisch zu tun. Wo kommt denn dann das Web-Framework zum Einsatz?
Genau, der Container schickt HTML-Code. Das ist mir schon klar. Aber wenn ich die Daten dann im Browser ordentlich darstellen will, muss es doch eine möglichkeit geben dies grafisch zu tun. Wo kommt denn dann das Web-Framework zum Einsatz?
Der Container kann neben HTML natürlich auch irgendwelche Bilder generieren und an den Client schicken, um sie dort in den HTML-Seiten einzubetten. Dafür bräuchte man dann entsprechende Chart-Frameworks bzw. Libs, die sowas können.
Richtig. Das Servlet ist die unterste Kommunikationsschicht zwischen (Java)WebServer und Browser. Selbst wenn du mit JSP arbeitest, macht der Webserver daraus ein Servlet.
Servlets ohne Hilfsmittel sind für eine normale Webseite eher ein mühsamer weg. Man muss die ganzen Html-Seiten, Formatierungen durch das Programm schleifen und in den OutputStream schreiben. Man könnte sich html-Seiten mit einem Webeditor erstellen und als Datei speichern. Das Serlvet könnte die Datei lesen und Daten ergänzen. Aber es gibt so viele fertige Lösungen, dass man das normalerweise nicht selber macht.
Eine JavaServerPage (JSP) ist ein angereicherte html-Seite. Die JSP kann man coden oder auch mit einem GUI-Editor zeichen. Mittels Tags und der Expression Language (EL) kann man die Seite mit Variablen/Javaklassen verknüpfen.
Die JavaServerFaces (JSF) gehen da noch einen Schritt weiter: Dort werden Komponenten wie eben z.B. eine Tabelle eingebettet. Es gibt auch bereits fertig Ajax-Zusätze für JSF (z.B. IceFaces).
Ob die GUI-Builder für für Webentwicklung was taugen, "entzweit" hier manchmal das Forum.
In letzter Zeit vergeht nicht ein Monat, in welcher kein Ajax-Framework auftaucht. Die Vielzahl der Frameworks ist auch der größte Hemmschuh für den deren Verbreitung.
Der Ansatz ist bei den meisten Frameworks ein ähnlicher:
+ fertige Widgets/Komponenten
+ GUI als xml-Beschreibung und/oder per Java-API (sehr ähnlich Swing)
+ Eventgesteuert
+ Programmierung sehr desktopähnlich
+ viel weniger Vorkenntnisse (Html, CSS, Javascript) notwendig
+ teilweise GUI-Builder erhältlich
- um solche Seiten ansehen zu können, muss im Browser Javascript aktiviert sein
- die Anforderungen an den Browser sind höher (Stichwort Mobile Endgeräte)
+/- Darstellung in den unterschiedlichen Browser von der Qualität des Frameworks abgängig
Das Framework meiner Wahl ist ZK. Man kann damit die GUI im Javastil (wie Swing) erstellen lassen oder
mit einer erweiterten XHTML-Datei beschreiben. Die Komponentensammlung ist recht groß und mächtig.
Bei meinen evaluierten Beispielen habe ca. 1/3 Zeilen (für die GUI-Beschreibung) von JSF benötitgt.
mMn ist das Framework einfacher als Swing zu erlernen - kein Layoutmanager, einfach beim Button onClick="javaklasse.methode()" hinterlegen - ohne anonyme Klasse.....
Also wenn es was einfaches werden soll (einfache DB, ein bis 3 Seiten zur Eingaben, Änderung und Anzeige der Daten im Browser) und du dich auch noch rein arbeiten musst, empfehle ich dir die Programmiersprache PHP und mySQL als DB. Damit findest du auch einfacher einen Server, der dies unterstützt.
Willst du was größeres machen oder interessierst du dich generell für Java/J2EE/JSF usw. dann steige mit Servlets und JSP's mal ein und dann auf JSF. Ich denke, damit hast du dann eine gute Basis, um tiefer zu gehen. Der Rest kommt dann automatisch bei der Suche nach neuen Features für deine Seiten. Aber bis du soweit bist, bist du erst einmal ordentlich beschäftigt.
das hört sicher alles interessant an. Kannst Du mir bitte näher erläutern, was ZK ist und wo es erhältlich ist. Ich möchte eigentlich nicht den ganzen HTML-Code, der zurückgegeben wird, in ein Servlet programmieren. Da denke ich, ist ein Framework (oder was gibt es sonst noch an dieser Stelle) schon das richtige. Ich habe leider noch keine Ahnung, wie ich das implementiere. Vielleicht hat jemand ein Beispiel für mich.
Mit PHP und mySQL möchte ich das nicht realisieren. Eigentlich möchte ich auch in die zukünftige Techniken investieren und flexibel sein. Trotzdem danke für den Vorschlag.
Vielleicht kennt ja einer ein anschauliches Beispiel. Ich würde mir das ganze auch gern mal fertig anschauen. Also auf einer fertigen HP.
Bevor ich jetzt über ZK "loslege" noch ein paar "Warnungen":
Unabhängig von der verwendeten Javatechnolgie ist es schwerer/teurer Webspace für Java zu finden, als z.B. für PHP oder Ruby.
Zwischen alles selber machen und einem Ajaxframework gibt es noch einiges Lösungen "dazwischen", z.B. JSP.
d.ausstroit hat gesagt.:
Eigentlich möchte ich auch in die zukünftige Techniken investieren und flexibel sein. Trotzdem danke für den Vorschlag.
Auch hier ist Vorsicht geboten. Ich finde ZK wesentlich einfacher und produktiver wie z.B. JSF. Das "Webfeeling" geht nicht nur beim Anwender, sondern auch beim Programmierer "verloren". Aber der Standard ist Moment doch Servlet/JSP/JSF. ZK ist zwar eines der aktivsten OpenSourceprojekte (immer zwischen Platz 1 und 5 auf Sourceforge), aber die endgültige Verbreitung ist noch nicht absehbar.
Zum Einlesen ein Vergleich aus dem Javamagazin: Struts vs JSF vs ZK
Du kannst da Programm auf dem Beitrag auch >> hier << ausführen. Das Befüllen der Liste wurde hier mittels Javacode realisiert. Ich habe das Beispiel auch mit Annotations/Databindings erstellt und konnte die ohnehin schon kürzeste Lösung nochmals deutlich an Code reduzieren.
Die Homgepage für Downloads und Dokus ZK ist: www.zkoss.org
Auch der Demoseite kannst du mit dem "Tryme-Button" jederzeit den dahinter liegenden Sourcecode anzeigen/verändern und mit deinen Änderungen neu anzeigen lassen.
Noch ein Beispiel zur Produktivität:
Wie du schon mitbekommen hast, wird JSF als komplex bezeichnet bzw. es wird der Lernweg von untern (Servlets - JSP - JSF, Javascript + fundierte HTML) empfohlen.
ZK verfolgt hier einen anderen Ansatz: fertige Komponenten, um HTML-Repräsentation und Javascript soll sich das Framework kümmern. Bei meinem Evaluierungsprojekt hatte ich nach ca. 1 Woche nach dem Start mit der ZK-Lernphase den Prototype meines Kataloges mit der Basisfunktionalität (nachladbarer Tree mit Produktfenster) fertig. Ein paar Wochen später stand das ganze Teil. OdKatalog
Nur nach Anmeldung sichtbar: Integration Webshop, CMS für Aktionen und Produktkorrekturen mit WYSIWYG-Editor).
Ich versuche gerade eine deutschsprachiges ZK Wissenseite zu erstellen - leider ist meine Zeit dafür recht knapp. Wenn du deine Anforderungen kurz umreißt, könnte ich mit einem Beispiel passend für dich anfangen.
danke für Deine umfassende Hilfe. Meine Anforderung habe ich oben weiter schon beschrieben. Es handelt sich dabei um eine DB-Anwendung über das Internet. D.h. Erfassungskräfte können über eine Suchmaske im Browser Daten eingegeben und nach der Bearbeitung der Treffer werden diese wieder in die DB geschrieben. Das ganze soll von mehreren Bedienern gleichzeitig durchgeführt werden können. Nun bin ich am überlegen, wie ich das ganze realisieren soll. Aber das steht oben ja schon alles genau beschrieben.
Ich bin grade dabei und schaue mir ICEfaces und Exadel an. Ist aber ziemlich umfangreich. Die Demos von der ZK-Seite finde ich eigentlich ganz ansprechend. Gibt es dafür ein Plugin für Eclipse? So wie Exadel. Damit lässt sich leicht eine GUI erstellen.
Was bedeutet denn Ajaxframework? Kann das wie ein normales Framework gesehen werden?
So, nun mache ich WE. Es wäre schön wenn Du mir weitere Tipps geben könntest.
Bis denne
PS: Bitte sag mir schnell, wie ich Deine Wissenseite erreiche!!! :wink:
So, ich habe mir mal den ZK vorgeknöpft. Dabei ist mir aufgefallen, dass beim Client JavaScript und ActiveX (bei manchen Componenten) aktiviert sein muss. Ist das immer so und ist das nicht ein Nachteil? Ansonsten gefällt mir das Handling eigentlich sehr gut.
Angesehen und auch in Eclipse eingebunden habe ich das Framework "EXADEL". Das gefällt mir vom Handling ausgezeichnet, weil unteranderem die Komponenten mit Drag & Drop auf die Seite gezogen werden können.
Was ich bisher noch nicht rausbekommen habe ist, welches Framework ist besser und für meine Belange geeignet? Ich hoffe das kann ich mit diesem Thema klären. Das wäre supi, denn ich muss mich möglichst schnell für eins entscheiden.
Vielleicht kennt jemand Frameworks, die sich ähnlich leicht handeln lassen. Bitte nennt mir diese Frameworks.
Mein Favorit in Sachen AJAX-Frameworks ist mit Abstand GWT (Google Web Toolkit). Auch dort programmiert man pures Java, das man dann mittels eines Java-to-JavaScript Compilers in JavaScript übersetzen lässt. Per RPC kann man asynchron mit dem Server kommunizieren (GWT-RPC, JSON, ...). Die GWT-API beinhaltet reichlich GUI-Widgets. Ein besonderer Clew ist der Hosted Mode Browser, mit dessen Hilfe man GWT-Webanwendungen wie eine Desktop-Anwendung debuggen kann. Das Ganze ist auch JUnit-fähig! Der Compiler erzeugt im übrigen Browserspezifischen JS-Code, so dass sich die Seite auf allen Browsern gleich verhält/ aussieht.
Die Lernkurve bei GWT ist imo sehr steil, wenn man Java und Swing oder SWT kann.
mMn ist das Framework einfacher als Swing zu erlernen - kein Layoutmanager, einfach beim Button onClick="javaklasse.methode()" hinterlegen - ohne anonyme Klasse.....
Nur weil ich weniger Code habe, kann man ja trotzdem noch debuggen. Wenn ich z.B. beim Button "Speichern" den Auruf "save" (=Methode im Controll) hinterlege, setzte ich den Breakpoint dort. Einfacher gehts eigentlich gar nicht: Im Eclispe den Breakpoint setzen, Server im Debugmodus starten und dann in der Debugansicht weitersteppen. Obwohl ich den meisten Fällen Logging vorziehe.
Zum Unterschied GWT und ZK:
GWT ist etwas clientlastiger. ZK definiert sich als Server-zentriertes Ajaxframework. Das will heißen: Von jedem "Web"desktop gibt es eine Kopie am Server, welche mit dem Browser (DOM) synchronisert wird. Um das Synchronisieren muss man sich nicht kümmen - das übernimmt ZK. Das hat zwar auch Nachteile (Resourcenverbrauch, langsameres Umschalten bei modalen Windows), aber jede Menge Vorteile (Spaltenbreiten, Fenstergrößen auch am Server) und ermöglicht Dinge wie einem shared Model welches z.B. Aktionkurse per "Serverpush" aktualisiert.
Praktisch bedeutet das noch mehr Desktopfeeling (bei der Programmierung) da ich z.B. einen Hintergrundthread weiter Daten an die GUI liefern kann.
zu JavaScript/ActiveX:
Es gibt kein Ajaxframewok das ohne Javascript auskommen wird. ActiveX ist bei ZK definitiv nicht dabei. Aber beim IE läuft das teilweise zusammen unter "Scripting".
Was die verschiedenen Frameworks angeht kann ich leider nicht wirklich weiterhelfen. Ich habe schon vorher geschriebenen, dass die Vielfalt wohl der größte Hemmschuh ist. Ich habe ZK, GWT, JSF mit ajax2jsf evaluiert. Das waren schon damals nicht alle und mittlerweile gibt jetzt wieder einige mehr (z.B. RAP = RCP-Webgegenstück).
zum Eclipse-Plugin:
Da dürfte EXADEL vorne sein. Ein (wahrscheinlich kommerzielles) Plugin steht unmitteltbar vor der ersten Version (zk-bench) und das ZK-Team hat für die Roadmap 2008 ein Eclipseplugin vorgesehen.
Derzeit gibt es eine >> Webversion (Onlinedemo) << (ZeroKode) die mit ZK selber gemacht ist. Hier kann man Komponenten in die Struktur ziehen, kopieren und verschieben und sieht rechts immer gleich das Ergebnis. Das Tool ist in der Form nur bedingt brauchbar. Ich habe es nur am Anfang verwendet, um ein Gefühl für die GUI zu bekommen - schon bald war ich mit dem XML-Editor (mit Parameterprompt, Autocompletion) schneller.
Zum Unterschied GWT und ZK:
GWT ist etwas clientlastiger. ZK definiert sich als Server-zentriertes Ajaxframework. Das will heißen: Von jedem "Web"desktop gibt es eine Kopie am Server, welche mit dem Browser (DOM) synchronisert wird. Um das Synchronisieren muss man sich nicht kümmen - das übernimmt ZK. Das hat zwar auch Nachteile (Resourcenverbrauch, langsameres Umschalten bei modalen Windows), aber jede Menge Vorteile (Spaltenbreiten, Fenstergrößen auch am Server) und ermöglicht Dinge wie einem shared Model welches z.B. Aktionkurse per "Serverpush" aktualisiert.
Ich sehe noch nicht so ganz, welchen Vorteil dieses server-zentriertes Konzept haben soll. Was will ich mit GUI-spezifischem Code auf dem Server? Server-Push kann ich auch mit GWT realisieren (ist zwar kein echter Push, weil die Initiative vom Client ausgeht, das Resultat ist aber das selbe).
Ich sehe da grade den Vorteil von GWT, dass nicht die ganze Last auf dem Server liegt sondern der Client arbeit übernimmt und der Server nur noch serviceorientiert arbeitet und keine Sessiondaten verwalten muss. Bei dem von Dir beschriebenen Konzept bleibt ja pro Client mindestens ein Server-Thread durchgehend offen. Das stellt bei vielen Usern doch extreme Anforderungen an den Server!?
Möchte aber ZK nicht schlecht reden, dafür kenne ich es nicht gut genug.
...
Ich sehe da grade den Vorteil von GWT, dass nicht die ganze Last auf dem Server liegt sondern der Client arbeit übernimmt und der Server nur noch serviceorientiert arbeitet und keine Sessiondaten verwalten muss.
Die Arbeitsweise von GWT und ZK ist sehr unterschiedlich: ZK lädt einmal die ZK Client Engine (Javascript) in den Browser und danach nur noch die die GUI-Komponenten für den DOM-Tree. GWT hat praktisch je GUI-Fenster eine Javascriptübersetzung samt Teilen Businesslogik (Prüfungen, Zugriffe!). An dieser Auslagerung stoßen sich die Sicherheitsexperten (z.B. >> hier << und >> hier <<.
Praktisch bedeutet dass für mich noch mehr Desktop-Feeling beim Programmieren: * Ich muss nicht unterscheiden ob das jetzt am Client läuft oder eine Remotefunktion ist. * Ich kann für lange Operationen die GUI von einem anderen Thread weiterbefüllen lassen. * Die Komponenten am Server werden auch immer aktualisiert. Wenn der User Fenster herumschiebt und Spalten verändert, bekomme ich das mit. * Keine "Kopfschmerzen" bezüglich Sicherheit: meine Javaklassen sind nicht einsehbar (auch nicht als Javascriptübersetzung) und alle Prüfungen laufen am Server.
byto hat gesagt.:
...
... keine Sessiondaten verwalten muss. Bei dem von Dir beschriebenen Konzept bleibt ja pro Client mindestens ein Server-Thread durchgehend offen. Das stellt bei vielen Usern doch extreme Anforderungen an den Server!?
Es wird einem schwer fallen, einen Serverthread mit einem Webclient zu verheiraten, aber die Anforderungen an den Server sind sicher höher als bei GWT und werden wohl im Bereich von JSF+Ajaxframework liegen.
Keine Frage, GWT hat was Geniales an sich. Aber ich hätte den Einsatz eher bei großen Komponenten (z.b. Liveticker..) als bei der Auslagerung von Businesslogik gesehen.
byto hat gesagt.:
...
...der Server nur noch serviceorientiert arbeitet und keine Sessiondaten verwalten muss.
BTW: Wie verarbeitet man im GWT den vor und zurück Button?
Aber die eigentlichen Gründe, warum ich mich für ZK entschieden habe:
1.) Die GUI-Beschreibungssprache: In der Regel läßt sich die GUI so kürzer beschreiben als mit Javacode. Auch die Verschachtelungen sind in XML übersichtlicher. Die XML/XHMTL-Komponenten heißen überigens gleich wie ihre Java-Gegentstück, auch die Parameter.
Ein GUI-Builder wäre natürlich das Optimum. Der jetzt verfügbare ZeroKode ist zwar nicht das Gelbe vom Ei, aber zeigt schon wohin die Reise geht: Rechte Maustauste auf der Komponenten (im Baum) auf Events und dort die Verknüpfung zur Javamethode herstellen, also z.B. für den Button "Speichern" beim Event "onClick" die Methode "save" hinterlegen. Verglichen mit manchen Webframeworks ein nahezu direkter Weg und wesentlich leichter für Quereinsteiger von anderen Programmierplattformen.
Was GUI-Builder angeht, bin ich bei ZK für dieses Jahr guter Dinge.
1b) Vollblut Swing/SWT-Programmierer können aber alles in Java machen, Eventlistener in anonymen Klassen machen usw.
2.) Sehr große Widget/Komponenten-Sammlung
Neben den Desktopstandards, vieles mehr wie Charts, Listen mit automatischen Paging usw.
Siehe auch die >> Demoseite << .
3.) Sehr aktive Community
ZK hat in den letzten 1 1/2 Jahre immer ein Platz zwischen 1 und 5 bei den aktivsten Projekten auf Sourceforge belegt. In letzten Monaten sind auch Komponenten der Community in das Projekt eingeflossen. Die Reaktionszeiten im Forum sind relativ kurz und auch die Entwickler antworten fleißig.
Auch ein anderes Sourceforge-TOP3-Projekt, ADempiere Bazaar hat bei der Evaluierung für den Ajax-Client für ZK entschieden (gegen Echo2, GWT, Dojo..).
4.) Schnelle Weiterentwicklung
Wenn man die Hauptseite bzw. die News ansieht, bekommt man einen Überblick über das Entwicklungstempo.
Das letzte Punkt ist erst während meiner Zeit mit ZK hinzugekommen:
5.) Annotation Databinding (ähnlich JSF)
Dabei hinterlegt man in der GUI-Beschreibung den Weg zum DatenBean, also z.B.
In der Controllerklasse muss es ein: Benutzer getBenutzer() geben bzw. auch einen Setter wenn es auch Eingaben gibt. Der Binder kann auch "Klassenpfade" abklappern, also wie in der 2. Zeile macht ein getBenutzer().getAbteilung().getName().
In vielen Fällen produziert der MVC-Pattern mehr Code, aber bei dieser Lösung wird der Code deutlich weniger. Der Transfer aus den Formularen in die Datenbeans und umgekehrt geht weitgehend ohne Javacode über die Bühne.
Also mMn verbindet ZK das Beste aus der Desktop und Webwelt. Ich arbeite nach wie vor auf anderen Plattformen und sehe dort, dass man sehr wohl Webapplikationen ohne große Vorkenntnisse zusammenklicken kann. Mit ZK kann man da noch am ehesten "mithalten".
6.) Scripting Variante
Ich verwende diese zwar nicht, aber möchte das auch nicht verschweigen:
Es ist möglich via <zscript>code</zscript> Javacode in die GUI einzupflanzen. Dieser Code wird per BeanShell interpretiert. Der Vorteil ist, dass die GUI-Komponenten bereits importiert sind:
<Textbox id="input" value="nix"/>
Ich kann im Code dann input.value="gar nix" ansprechen. Die Entwicklung der Script-Variante kann dann ähnlich PHP/Ruby laufen: mit dem Texteditor am Weberserver ändern - kein deployen, kein Neustart. Die Scriptingsprache läßt sich auch auf Ruby, Grails oder Javascript(Serverseitig!) einstellen.
@d.ausstroit
Hast du vor eine Persistinzschicht zu verwenden?
wenn mit Persistenzschicht die Schicht gemeint ist, die als Schnittstelle zwischen einer Anwendung und einer Datenbank gemeint ist, sage ich mal ja. Denn geplant habe ich eigentlich eine 4-Schichten-Architektur. Wir beschäftigen uns zur Zeit mit mehreren Entwicklern mit diesem Thema. Wenn ich ehrlich bin, ist das ganze doch eher Neuland für uns. Aber jeder fängt ja mal klein an .
Ich tue mich immer noch schwer damit, zu entscheiden, welches Webframework wir einsetzten sollen. Bisher haben wir unsere Anwendungen mit dem Borland C++Builder realisert. Da sind wir, was Maskenerstellung betrifft, doch sehr verwöhnt. Wie ich schon weiter oben erwähnte, möchten wir unseren Kunden auch weiterhin leicht bedienbare Dialogmasken anbieten. Wenn möglich mit dem gleichen oder wenigstens ähnlichen Bedienkomfort, wie bei einer Desktop-Applikation. Ist das übehaupt realistisch?
Daher bin ich immer noch auf der Suche nach Beispielen für Dialogmasken, welche mit Webframeworks erstellt wurden. Egal, ob diese Frameworks etwas kosten oder nicht. Wichtig ist, dass sie sich in eine IDE integrieren lassen.
Vielleicht kann mir jemand noch ein paar Tips geben. Bisher hat mir diese Diskussion jedenfalls sehr weitergeholfen. Es fällt mir doch wesentlich leichter den Zusammenhang zu verstehen.
Robert, hat Du vielleicht ein einfaches ZK-Bespiel. Wenn es geht für Eclipse. Es wäre super, wenn es die ein oder andere Komponente enthalten würde. Dann könnte ich mich da mal rein knien.
Die Arbeitsweise von GWT und ZK ist sehr unterschiedlich: ZK lädt einmal die ZK Client Engine (Javascript) in den Browser und danach nur noch die die GUI-Komponenten für den DOM-Tree. GWT hat praktisch je GUI-Fenster eine Javascriptübersetzung samt Teilen Businesslogik (Prüfungen, Zugriffe!). An dieser Auslagerung stoßen sich die Sicherheitsexperten (z.B. >> hier << und >> hier <<.
Das ist so nicht ganz richtig. Es kommt sehr stark darauf an, wie Du eine GWT-Anwendung entwirfst. Die Business-Logik sollte natürlich nicht übersetzt in JS auf dem Client laufen sondern als Service auf dem Server bereit stehen. Die Services liefern die Daten dann zur Darstellung an die JS-Seiten. Diese dienen auch lediglich als Views.
Aber sicherlich hast Du nicht unrecht, dass Sicherheit ein heikles Thema bei AJAX-Anwendungen ist. Das trifft aber nicht nur auf GWT zu.
Praktisch bedeutet dass für mich noch mehr Desktop-Feeling beim Programmieren: * Ich muss nicht unterscheiden ob das jetzt am Client läuft oder eine Remotefunktion ist. * Ich kann für lange Operationen die GUI von einem anderen Thread weiterbefüllen lassen. * Die Komponenten am Server werden auch immer aktualisiert. Wenn der User Fenster herumschiebt und Spalten verändert, bekomme ich das mit. * Keine "Kopfschmerzen" bezüglich Sicherheit: meine Javaklassen sind nicht einsehbar (auch nicht als Javascriptübersetzung) und alle Prüfungen laufen am Server.
Wie gesagt: Das ganze erkauft sich ZK aber durch eine extreme Last auf dem Server, da pro Client kontinuierlich mind. ein Thread ackert.
Keine Frage, GWT hat was Geniales an sich. Aber ich hätte den Einsatz eher bei großen Komponenten (z.b. Liveticker..) als bei der Auslagerung von Businesslogik gesehen.
Ja, das sehe ich auch so. Du kannst mit GWT sehr schön und einfach komplexe Web GUIs bauen. Natürlich sollte die BL in Sicherheit bleiben - auf dem Server.
byto hat gesagt.:
...
...der Server nur noch serviceorientiert arbeitet und keine Sessiondaten verwalten muss.
Da habt ich auch noch einen "Brocken" vor euch. Es zwar nicht so, dass man lange braucht bis es läuft, aber das man alle Caching-Mechanismen, Verknüpfungen usw. kennt, kann es schon etwas dauern.
Wenn ihr bestehende Datenbanken habt, empfehle die Hibernate Tools (EclipsePlugin) zum Import mit EJB3 konformen Annotationen. Laß dich nicht von alten Tuturials im Netz zu XML-Beschreibungen hinreißen. Selbst die Hibernateentwickler raten zur Verwendung von EJB3-Annonations. Damit bleibt der Code weitgehend Javastandard (Ausnahme: Spezialoptionen wie Cache usw.) und bei der Wahl deiner EJB3-konformen-Perstenzschicht bzw. dem EE-Server flexibel.
Eine fertig definierte Persitenzschicht ist natürlich eine feine Sache. Hier kann man sich mit der IDE durch die Daten/Fileklassen durchprompten. Auch die "Leseorgien" für die Bezeichnungen vor der GUI-Ausgabe kann man mit Databinding eindämmen: value="@{controller.auftrag.kunde.name}" holt vom Auftrag den Kundensatz und holt daraus den Namen des Kunden an. Bis es soweit ist, steht allerdings noch Arbeit bevor. Speziell bei Altdatenbanken ist es auch nicht immer leicht ein einigermaßen objektiorentiert Modell dafür abzubilden.
d.ausstroit hat gesagt.:
Ich tue mich immer noch schwer damit, zu entscheiden, welches Webframework wir einsetzten sollen.....a sind wir, was Maskenerstellung betrifft, doch sehr verwöhnt
Es ist auch nicht so einfach. Es gibt kaum jemanden, der mit vielen geschweige denn mit allen Ajax-Frameworks gearbeitet hat. An Frameworks mit GUI-Builder kenne ich noch RAP. Was ZK angeht, hoffe ich auf zk-bench, wobei mit der jetztigen Lösungen (prompten der Java-API bzw. der XML-Tags) auch nicht unzufrieden bin.
d.ausstroit hat gesagt.:
....wir unseren Kunden auch weiterhin leicht bedienbare Dialogmasken anbieten. Wenn möglich mit dem gleichen oder wenigstens ähnlichen Bedienkomfort, wie bei einer Desktop-Applikation. Ist das übehaupt realistisch?
Meiner Meinung nach ja - wenn auch mit leichten Abstrichen bei der Geschwindigkeit und der Kontrolle (z.B. Sprungreihenfolge der Tabtaste) und kleinen Überraschungen (Tastaturpuffer zwischen den Seiten inaktiv/gelöscht).
Da wir noch viele GreenScreen-Anwendungen haben, war uns die Tastasturbedienbarkeit wichtig. Fast alle Komponenten von ZK haben auch eine Tastaturbedienung, außerdem sind Funktion- und Steuertasten (z.B. CTRL a) abfragbar.
d.ausstroit hat gesagt.:
Daher bin ich immer noch auf der Suche nach Beispielen für Dialogmasken, welche mit Webframeworks erstellt wurden.
Die die meisten doch Intranetanwendungen damit erstellen, sind die frei zugänglichen Anwendungen Mangelware. Außer den bereits oben angeführen Links und der ZK-Demoseite, ist mir nichts bekannt.
... Die Business-Logik sollte natürlich nicht übersetzt in JS auf dem Client laufen sondern als Service auf dem Server bereit stehen. Die Services liefern die Daten dann zur Darstellung an die JS-Seiten. Diese dienen auch lediglich als Views. Aber sicherlich hast Du nicht unrecht, dass Sicherheit ein heikles Thema bei AJAX-Anwendungen ist. Das trifft aber nicht nur auf GWT zu.
Wie du schon richtig gesagt hast: Sicherheit ist ein heikles Thema und muss bei der Programmierung berücksichtigt werden. Die Schwachstelle sind sicher die (SOA) Services, welche man nach außen offen hat. Genau das wurde z.b. bei GMail ausgenutzt. Mitunter bedeutet das, dass man Prüfungen mehrfach machen müßte. Es reicht nicht nur wenn ich der GUI bestimmte Felder prüfe/sperre - der Service muss das nocheinmal machen. Das trifft nicht nur auf GWT zu, sondern auf die meisten anderen Ajax-Frameworks.
Mit ZK braucht man keine Services von außen zugänglich zu machen. Hier kann man maximal GUI-Services aufrufen, aber selbst in der GUI definierte Prüfungen werden am Server ausgeführt (beim Zurückmappen). In Sachen Sicherheit gibt es bei ZK wesentlich weniger Angriffsfläche als mit Client-Ajax-Frameworks. Der Nachteil: siehe nächster Punkt.
Wie gesagt: Das ganze erkauft sich ZK aber durch eine extreme Last auf dem Server, da pro Client kontinuierlich mind. ein Thread ackert.
Keine Frage, im Vergleich zu einer GWT-Anwendung sind die Serveranforderungen x-fach höher. ZK wird sich bei den Anforderungen im Bereich anderer serverlastiger Frameworks (z.B. JSF) finden. Praktisch kratzen 150-Sessions meines Onlinekataloges einen 3GHz-PC (DualCore) überhaupt nicht (5-20% CPU-Auslastung).
Ich sehe schon bei jetztiger Serverhardware (2x4 Cores!) mit der (noch zu erstellenden) Software der nächsten Jahre für 700 Benutzer kein Problem. Noch dazu braucht man aus Ausfallsgründen mindestens 2 Server für den Cluster.
Auch auf schwacher Hardware (Vserver) läuft ZK eigentlich nicht so schlecht.
Nein. Die erste Version wäre für Jänner angekündigt.. Aber nachdem sie jetzt ihr ZK-Buch fertig haben, sollten sie wieder mehr für zk-bench haben.
Erst gestern ist mit ZK-Studio 0.5 ein neues Eclipse-Plugin hinzugekommen. Damit hat man auf Knopfdruck ein neues vordefiniertes ZK-Webprojekt.
Robert, hat Du vielleicht ein einfaches ZK-Bespiel. Wenn es geht für Eclipse. Es wäre super, wenn es die ein oder andere Komponente enthalten würde. Dann könnte ich mich da mal rein knien.
Ich sollte in den paar Tagen soweit sein, meine Beispiele zu hosten. Von der War-Datei kannst du dann ein Eclipseprojekt erstellen. Das Beispiel ist vom Struts vs. JSF vs. ZK Bericht (alle Links schon oben gepostet). D.h. die Sourcen sieht man schon im PDF. Davon habe ich ein paar Versionen 1xListbox, 1xGrid, Annotations Databinding und Output-Converters.
Bei den Convertern bin dann etwas "vom Weg abgekommen". Es war nämlich "verflucht einfach" einen (Model)Converter für SQL-ResultSets (Output) zu machen. Wenn ich noch etwas Arbeit invenstiere, wäre
das GUI-JDBC-Binding beidseitig möglich..ganz wie in VisualStudio-Zeiten - nur besser.
Ich poste es hier, wenn die Datei downloadbar ist.
BTW, hier noch etwas LOC-Statistik vom Beispielprogramm (ZK: meine Verison mit Annotation)
Framework, Lines, Zeichen
JSF, 184, 6091
Struts, 274, 8103
ZK, 112, 3852
Mit ZK braucht man keine Services von außen zugänglich zu machen. Hier kann man maximal GUI-Services aufrufen, aber selbst in der GUI definierte Prüfungen werden am Server ausgeführt (beim Zurückmappen). In Sachen Sicherheit gibt es bei ZK wesentlich weniger Angriffsfläche als mit Client-Ajax-Frameworks. Der Nachteil: siehe nächster Punkt.
Klingt interessant, aber so ganz verstehe ich das Konzept noch nicht. Die Views sind doch auch in JavaScript übersetzt und wird dann zur Darstellung auf den Client geladen. Wie funktioniert nun die Kommunikation mit dem Server? Und warum ist dieser sicherer als bei anderen Frameworks?
Mit ZK braucht man keine Services von außen zugänglich zu machen. Hier kann man maximal GUI-Services aufrufen, aber selbst in der GUI definierte Prüfungen werden am Server ausgeführt (beim Zurückmappen). In Sachen Sicherheit gibt es bei ZK wesentlich weniger Angriffsfläche als mit Client-Ajax-Frameworks. Der Nachteil: siehe nächster Punkt.
Klingt interessant, aber so ganz verstehe ich das Konzept noch nicht. Die Views sind doch auch in JavaScript übersetzt und wird dann zur Darstellung auf den Client geladen. Wie funktioniert nun die Kommunikation mit dem Server? Und warum ist dieser sicherer als bei anderen Frameworks?
Vom ganzen "Web"Desktop gibt bei ZK 2 Exemplare: 1x den DOM-Baum des Browser, 1x am Server in Form. Wenn der User jetzt Änderungen im Formular vornimmt markiert die Client-Engine geänderte Komponenten im DOM-Baum. Wenn jetzt ein Serverevent ausgelöst wird (einfacher Fall: onClick bei einem Button mit der Funktion Save) dann werden alle Events/Veränderungen an das Event-Servlet übermittelt, d.h. zuerst die Feldänderungen und dann das onClick-Event.
Die Prüfungen (selbst die in der GUI-Schicht definierten) laufen alle am Server bevor dann die Verarbeitung stattfindet.
Zum Vergleich: Bei einer clientlastigen Realisierung läuft es darauf hinaus, dass beim "Speichern" die entsprechende SOA-Funktion aufgerufen wird (welche bei ZK nicht offen ist bzw. gar nicht gibt). Hier muss man nocheinmal alles prüfen, selbst wenn der Wert in der GUI nur Output war, durch eine Listbox beschränkt oder bereits vorher durch einen SOA-Aufruf (z.B. Kunennummer) geprüft wurde. Dann bleiben noch immer "eigentlich" gültige Aufrufe, die aber per Programm in unnatürlicher Anzahl (z.B. Funktion Freunde einladen., Missbrauch von Suchhilfen für Datenabausaugen..).
Man kann natürlich clienlastige Lösungen absichern - aber es gibt mehr zu Bedenken. Auch ZK ist nicht vor allen Angriffen (z.b. die eigentlich gültigen Aufrufe + "normale" Webschwachstellen) gefeit, allerdings ist es deutlich schwieriger sich in ein komplexes GUI-Framework einzuklinken, als die zumeist einfachen SOA-Aufrufe nachzubauen.
Zur Vervollständigung der ZK-Architektur:
Auf Serverseite gibt es ebenfalls die markierten geänderten Komponenten. Diese werden dann als Antwort zurückgesendet. Ich bin immer wieder verblüfft, wie viel da schon ohne mein zutun funktioniert.
Vom ganzen "Web"Desktop gibt bei ZK 2 Exemplare: 1x den DOM-Baum des Browser, 1x am Server in Form. Wenn der User jetzt Änderungen im Formular vornimmt markiert die Client-Engine geänderte Komponenten im DOM-Baum. Wenn jetzt ein Serverevent ausgelöst wird (einfacher Fall: onClick bei einem Button mit der Funktion Save) dann werden alle Events/Veränderungen an das Event-Servlet übermittelt, d.h. zuerst die Feldänderungen und dann das onClick-Event.
Die Prüfungen (selbst die in der GUI-Schicht definierten) laufen alle am Server bevor dann die Verarbeitung stattfindet.
Es ist dabei also auch nicht möglich, den DOM-Baum zu manipulieren, um falsche Anfragen an den Server zu stellen (sagen wir mal eine ListBox um neue Einträge zu erweitern)? Das würde ZK merken wegen der Differenz zw. den beiden Bäumen nehme ich an?
Klingt interessant. Wobei man auch dazu sagen muss, dass man ja auch die Services bei einem clientzentrierten Framework wie GWT absichern kann. Frameworks wie Acegi können einem da schon viel Arbeit abnehmen. Und nicht immer ist es notwendig, den ganzen Wertebereich der Parameter zu überprüfen.
Muss aber auch dazu sagen, dass ich bisher mit AJAX nur in einem Kontext gearbeitet habe, wo dieser Sicherheitsaspekt nicht sehr viel wiegt (Intranetanwendung ohne sehr sicherheitskritische Daten).
.
