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.
Wofür ist JSF eigentlich gemacht? Webseiten oder Webapps?
wo ich mich gerade mal wieder mit JSF beschäftige, frage ich mich, wofür JSF ursprünglich eigentlich gemacht war. Standen die Webseiten im Vordergrund mit dem typischen Webseitenlayout? (d.h. Titel oben, dann viele bunte Graphiken etc.) oder stand auch die Entwicklung von Webanwendungen, die den heutigen Desktop-Anwendungen ähneln im Vordergrund? (d.h. oben eine Menüleiste, dann eine Toolbar etc.)
JSF ist ja eigentlich auch eher Seiten-orientiert oder? D.h. es gibt Request, Session und Application Scope etc. Das würde andeuten, dass man eher von Webseiten ausgegangen ist. Ist dann die Verwendung von JSF für tatsächlich eher daten-getriebene Anwendungen, wie man es vom Desktop her kennt der falsche Anwendungszweck für JSF?
Ah, das ist interessant, danke. Ich habe mich bei meiner Frage primär an aktuellen JSF-Implementierungen orientiert, die eben primär das Erstellen von heute üblichen Webseiten ermöglichen. Natürlich sind das schon umfangreiche Komponenten, aber es sieht alles sehr web-mäßig aus.
Wenn es eigentlich das Swing fürs Web ist, dann vermisse ich etwas mehr die typischen und vor allem gut-aussehenden Komponenten. ExtJS for JSF wäre hier einfach der Hammer.
Ich habe mich bei meiner Frage primär an aktuellen JSF-Implementierungen orientiert, die eben primär das Erstellen von heute üblichen Webseiten ermöglichen.
Standen die Webseiten im Vordergrund mit dem typischen Webseitenlayout? (d.h. Titel oben, dann viele bunte Graphiken etc.) oder stand auch die Entwicklung von Webanwendungen, die den heutigen Desktop-Anwendungen ähneln im Vordergrund?
schon klar Ich meinte nur, dass die JSF-Implementierungen natürlich Komponenten bereitstellen, was somit an Swing erinnert. Aber auf der anderen Seite sind die Komponenten einfach vom Look and Feel her nicht das, was man sich für eine ordentliche Webanwendung wünscht. Mir hat einfach eine JSF-Implementierung gefehlt, die Komponenten wie in ExtJS oder so bereitstellt.
wenn du nicht willst das es nach Web aussieht, warum sollte man dann überhaupt "Web" machen, wo es doch so viele Nachteile gegenüber "echten" Clients hat?
JavaScript, AJAX etc. pp. sind doch nur Versuche, diesem dummen Browser ein paar mehr fähigkeiten zu verpassen als nur Dokumente auszuliefern.
Hand aufs Herz, JavaScript und AJAX sind auch nur Krücken, um den Browser wenigstens ein bisschen humpeln zu lassen
Wenn du "wirklich" ein Desktop-Feeling im Browser haben willst kannst du dir diverse AJAX-Frameworks anschaun. Mein Favorit ist dabei ThinWire. Da programmierst du reines Java (kein JavaScript oder HTML). Das ganze ist Event basiert, man kann daher wirklich wie eine normale Application entwickeln.
Ohne JavaScript und CSS wird das wohl nix, und das ist ja bekanntlich unterschiedlich bei unterschiedlichen Browsern und Browserversionen, speziell wenn es gut aussehen soll wirds kompliziert.
Den Aufwand, CSS und JS auf allen Brwosern zum laufen zu bringen, sollte man keinesfalls unterschätzen.
> Ohne JavaScript und CSS wird das wohl nix
Auf PC-Seiten auf jedenfall notwendig.
Bei Handy-Seiten nicht.
> unterschiedlich bei unterschiedlichen Browsern und Browserversionen, speziell wenn es gut aussehen soll wirds kompliziert.
Glaub du interpretierst jetzt das falsch.
Es geht mir nicht darum, dass alle User das zu 100% korrekt ansehen/nutzen können.
Der Vorteil ist, dass es immer erreichbar ist.
Für jeden: Anonyme User, Interressenten, potentielle Kunden ... ohne irgendwelche Installationen
Von überall: Arbeit, Aussendienst, Schule, Internetcaffee, Krankenhaus, im Stau, ...
Endgerät: PC, Handy, PDA, ...
> Den Aufwand, CSS und JS auf allen Brwosern zum laufen zu bringen, sollte man keinesfalls unterschätzen
Ja - blöd und nervig
Allerdings kommt eben auch bei Standardprogrammen irgendwann n Kunde daher:
"Ich würde gerne meine Daten ins Internet stellen"
Dann kehrt sich das wieder um, denn bei Webanwendung:
- Kaum Aufwand für die Umstellung
- Coder arbeitet mit gleicher Technik weiter
- Basic Sourcen existieren schon
Glaub du interpretierst jetzt das falsch.
Es geht mir nicht darum, dass alle User das zu 100% korrekt ansehen/nutzen können.
Der Vorteil ist, dass es immer erreichbar ist.
Dachte "ist von jeden, von überall, auf unterschiedlichen Endgeräten nutzbar" heisst soviel wie: Funktioniert immer von jedem Endgerät aus.
Mache auch schon lange Webanwedngen mit Java, hab oft schon den IE verflucht, der aktuelle Kunde nutzt ausschliesslich das IE, somit hab ich zwar das Problem nicht mit Opera & FF kompatibel sein zu müssen, aber die verschiedenen IE Versionen reichen schon um genervt zu sein...
Naja, der Browser, HTML und HTTP waren nicht für Anwendungen gemacht, genaugenommen vergewaltigen wird das immer wieder... worauf ich hinaus wolte: Wenn es stört das es nach Web aussieht, warum denn dann Web?
Web, weil eben keine zusätzliche Anwendung als ein Browser vorhanden sein muss. Natürlich gibt es auch Webstart, Applets etc. Aber das erfordert immer eine JVM auf dem Rechner.
Ich mag die Technologie, nur eben nicht das Aussehen. Und ich denke nicht, dass Web automatisch heißt, dass oben ein Titel sein muss, darunter eine bunte Navigationsleiste, wie man es halt so kennt.
JavaScript und AJAX etc. sind natürlich in gewisser Weise Frickelei. Aber die heutigen Frameworks verschatten das ganze hervorragend. Es gibt für mich daher keinen Grund auf JavaScript/AJAX zu verzichten. Sehe es als durchaus interessante Möglichkeit an, Anwendungen zu schreiben, die über einen Browser von überall zugreifbar sind.
Wenn man sich ExtJS anschaut, dann kann Web eben auch ganz anders aussehen. Und das finde ich sehr interessant. Frage war eben nur, ob JSF hierfür die passende Technologie ist. Oder ob man, wenn man eben nicht das klassische Layout haben möchte, sondern auf klassische Desktop-Funktionalität hinaus will, auf sowas wie GWT oder ähnliches ausweichen soll.
> Wenn man sich ExtJS anschaut, dann kann Web eben auch ganz anders aussehen. Und das finde ich sehr interessant.
Also die ExtJS Demo Komponenten fand ich auch sehr beeindruckend.
Vermiss da allerdings grössere Beispiele.
Haste schon mal probiert wie sich ein editierbares Grid bei > 1000 Zellen verhält/läd?
> JSF hierfür die passende Technologie ist
Also geht natürlich auch mit JSF, allerdings wirst du eigene JSF-Renderer evt sogar JSF-Komponenten dafür proggen müssen, die eben ExtJS konformen Response zurückliefern.
JSF ist nicht ohne - sollte man schon mit mehreren Monaten Einarbeitung rechnen.
Besser wäre es natürlich wenn die ExtJS Jungs das passend liefern würden.
Ansonsten haste nämlich auch das Problem, dass du bei neuen ExtJS-Versionen dein JSF-Zeugs nachziehen musst.
Würd da einfach mal anfragen ob was in Planung ist.
nein ein Grid > 1000 Zeilen habe ich noch nicht getestet.
Es gibt bereits ein Projekt, was versucht hat ExtJS mit JSF zu verbinden mit Namen lilya. Allerdings wird das glaube ich nicht mehr weiterentwickelt.
Bei JSF hat man halt Request, Application etc. Scope. Ist die Frage, ob das für solche Anwendungen geeignet ist und man überhaupt so programmieren möchte. GWT verschattet sowas und man entwickelt im Grunde seine Anwendung mit Listenern etc. wie man es von Swing her kennt.
> nein ein Grid > 1000 Zeilen habe ich noch nicht getestet.
Zellen net Zeilen
Glaub 1000 Zeilen hab ich noch nirgens gebraucht.
> Bei JSF hat man halt Request, Application etc. Scope.
Hm weiss jetzt nicht wie das GWT macht, also ich find schon gut wenn man überlegt in welchen Scope man n Objekt schmeisst.
Mein RAM auf dem Server ist ja auch begrenzt.
Leider in JSF auch viel zu oft SessionScope notwendig.
Eigentlich sollten 1000 Zeilen kein Problem sein - aber die Praxis sagt oft was anderes. Der gleiche Output, welcher bei Opera 1 Sekunde dauert, braucht am IE über 30 Sekunden....
Je nach Framework kann das Paging recht einfach zugeschaltet werden (z.B. ZK eine Zeile für das Paging)
Terminator hat gesagt.:
Hm weiss jetzt nicht wie das GWT macht, also ich find schon gut wenn man überlegt in welchen Scope man n Objekt schmeisst.
Mein RAM auf dem Server ist ja auch begrenzt.
Leider in JSF auch viel zu oft SessionScope notwendig.
Wenn RAM-Verbrauch auf dem Server ein Thema ist, bist du wohl mit GWT gut beraten. Hier schreibst du den Client-Teil in Java (der dann später in Javascript übersetzt wird) und kommunzierst über SOA-Funktionen mit dem Server. Du weißt also immer, was im Browser läuft und was am Server. Was ich an GWT etwas vermisse sind die Funktionen für Datenbanklastige Anwendungen ala Databinding und MVEL.
Noch zu JSF:
Wird auch mit Ajax die meist benutzte Lösung werden/bleiben. Dabei wird das ohnehin schon komplexe JSF nochmal um AJAX-Zusätze "verkompliziert" - also meine Vorstellung von schneller Softwareentwicklung ist das nicht.
Das Problem mit den Ajax-Frameworks ist eigentlich nur, dass es zu viele davon gibt. Kaum ein Thread zu dem Thema, wo einmal 2 Leute das selbe Ajax-Framework verwenden....
So habe auch ich meinen eigenen Favoriten: ZK
Die Komponenten sind ähnlich wie bei extJS, es gibt sogar von extJS eingebundene.
Beim Programmieren gibt es keine Unterscheidung ich mache jetzt Server oder Client - programmieren wie für Desktop.
Die GUI kann per XML oder Java (ähnlich Swing) beschrieben werden. Hier mögen sich die Geister scheiden - aber ich bevorzuge die XML-Tags. Es ist einfach eleganter (und weniger Code) wenn ich z.B. bei einem Button einfach nur die Methode angeben brauche (Listener macht er selber).
Ich finde den Java-Code viel eleganter als die XML-Hell. Ich weiss nicht welche IDE Du benutzt, aber beispielsweise in Eclipse ist der XML-Editor eher schlecht. Was passiert, wenn Du Refactoring im Controller machst - z.b. die save-Methode umbenennst? Gibts für ZK ein hübscher Plugin oder musst Du die XML dann von Hand anpassen?
> aber die Praxis sagt oft was anderes
yeap das hab ich gemeint - Beispiele sollte man erst mal mit mehr Daten checken.
> Du weißt also immer, was im Browser läuft und was am Server
Wie meinst du das - muss man doch bei jedem Framework wissen.
> RAM
Also wenn der Client Teil in Java geschrieben wird, dann wird doch bestimmt ähnlich wie bei JSF ein serverseitiger KomponentenTree oder hier dann vielleicht ein NodeTree aufgebaut.
Wenn der State dieses Tree beim Response für Änderungen zur Verfügung stehen muss, wird auch bei dieser Technik der Tree in Session oder wenn vorhanden in Page Scope gespeichert.
=> braucht genauso viel RAM
(Ausnahme wäre komplette Serialisierung des Trees zum Client)
> Databinding und MVEL
Sorry kenn ich nicht.
Was bringt das denn an Performance bei DB-Lastigen-Apps gegenüber JDBC?
> JSF-AJAX
Stimm ich dir zu.
Hab mich deshalb auch dazu entschieden das einfach selber zu machen.
Zwar evt nicht so schnell in Entwicklung, aber dafür voll flexibel und unabhängig.
> ZK
Layout find ich noch nicht so ausgereift wie das bei ExtJS
Konzept klingt eigentlich ganz gut, meiner Meinung ist das ähnlich JSF.
Kann auch in JSF Client-Code komplett am Server erstellen/rendern, wenn man das mag.
Schätz mal bei ZK wird der Vorteil sein, dass Commuikation/Datenaustausch zw. Client/ClientKompos und Server/ServerKompos schon absolut automatisiert sind.
Das ist dann schon geil - denk kommt bestimmt bei JSF auch noch mehr in die Richtung.
in IDEA wird übrigens der Code angepasst... und ich frage mich, warum das mit dem XML-Editor in Eclipse nicht auch funktioniert. Gerade das Renaming-Refactoring ist für mich daher in Eclipse völlig unbrauchbar geworden... keine spring-config angepasst, keine hibernate.cfg und die .hbms erst recht nicht.. - super Lösung!
Zur Beschreibung von Seiteninhalten, halte ich XML übrigens nach wie vor für gut - eine gute IDE vorausgesetzt - und auch für besser, als das programmatische Tippen von Seiten - das will ich nicht - Gerade wenn man Templating macht und ineinanderschachteln will, ist dieser HTML-Ansatz bei mir so verankert, dass ich mich mit "programmatischen" Lösungen nicht anfreunden kann.
Was bei JSF imho stört, ist der Komponentenbaum, der immer entweder im Speicher des Servers hocken muss oder aber vom Client in der Seite gehalten wird und jedesmal mit übertragen wird (was imho noch schlimmer ist - denn Speicher muss ich ausgeben, lange Übertragungsraten der Kunde oder noch schlimmer ein potentieller Kunde).
Also aktuell pendel ich ja noch zwischen Grails (groovy) und JSF - ich schätze wir werden hier beide Lösungen weiter verfolgen und gespannt auf die Struts2-Entwicklung gucken - auch wenn ich da einige Ansätze nicht ganz so dufte finde. Bei JSF hat man einfach noch viel mehr zusätzliche Addons, wie z.B. Facelets...
in IDEA wird übrigens der Code angepasst... und ich frage mich, warum das mit dem XML-Editor in Eclipse nicht auch funktioniert. Gerade das Renaming-Refactoring ist für mich daher in Eclipse völlig unbrauchbar geworden... keine spring-config angepasst, keine hibernate.cfg und die .hbms erst recht nicht.. - super Lösung!
Nicht ganz richtig. Mit dem Spring IDE Plugin für Eclipse funktioniert zumindest für Spring das Refactoring in den XML-Beans (Rename, Move). Content Assist gibts auch in der XML. Da kann man kaum meckern. Das einzige, was bei mir nicht funktioniert, ist Content Assist und Refactoring beim angeben der gemappten Klassen in der SessionFactory-Bean. Da besteht noch Nachholbedarf.
Hibernate.cfg und .hbm kann ich grade nicht testen, weil ich grad nur ein Spring-Projekt zur Hand habe.
Zur Beschreibung von Seiteninhalten, halte ich XML übrigens nach wie vor für gut - eine gute IDE vorausgesetzt - und auch für besser, als das programmatische Tippen von Seiten - das will ich nicht - Gerade wenn man Templating macht und ineinanderschachteln will, ist dieser HTML-Ansatz bei mir so verankert, dass ich mich mit "programmatischen" Lösungen nicht anfreunden kann.
Sehe ich anders, aber da scheiden sich wohl die Geister. Ich finde XML eigentlich ziemlich unbrauchbar als "Programmier"-Syntax. Für mich ist XML eine reine Datenbeschreibungssprache, die imo auch nur Computer sprechen sollten. Sehe auf jeden Fall keine Vorteile gegenüber der programmatischen Lösung. Klar kommt man nicht drum rum bei vielen Websprachen, insofern stellt sich die Frage ja auch nicht, was man verwendet. Aber wenn ich die Wahl hätte, würde ich (persönlich) immer die programmatische Lösung bevorzugen.
Hm weiß nich - das ineinander Schachteln von Layout geht via XML-Dialekte eigentlich doch sehr gut... - wenn ich das programmatisch mache, hab ich ein schachteln über container, à la component1.add(component2.add(xyz)); - wenn man zuviel schachtelt, seh ich nischts mehr - das kenn ich aus meinen Swing-Zeiten... - je mehr Panels man hat, die ineinander gepackt werden, desto unübersichtlicher wird's ... via XML kann ich hübscher schachteln... - Nachteile sind da halt die momentan noch unzulängliche IDE-Unterstützung...
viel schlimmer bei der xml-hell find ich den nervtötenden Zwang wirklich alles via XML konfigurieren zu wollen... - aber bei klassischem Markup sehe ich dann doch Vorteile.
Zur Spring-XML-Unterstützung... okay - das hatte ich nicht getestet, dann ist das Spring-Plugin-Projekt halt besser, als das normale XML-Editor-Projekt... - aber der Eclipse-XML-Editor ist sowieso der letzte Grütz! und somit auch die Verbindung mit dem Hibernate-Kram... und das Hibernate-Plugin ist bei dem Editor auch eher unbrauchbar... obwohl ich jetzt immerhin die DB-Connection hinbekommen hab.
Hm weiß nich - das ineinander Schachteln von Layout geht via XML-Dialekte eigentlich doch sehr gut... - wenn ich das programmatisch mache, hab ich ein schachteln über container, à la component1.add(component2.add(xyz)); - wenn man zuviel schachtelt, seh ich nischts mehr - das kenn ich aus meinen Swing-Zeiten... - je mehr Panels man hat, die ineinander gepackt werden, desto unübersichtlicher wird's ... via XML kann ich hübscher schachteln... - Nachteile sind da halt die momentan noch unzulängliche IDE-Unterstützung...
OK, da geb ich Dir recht. Die Hierarchie kann man da besser sehen. Ist wohl am Ende einfach Gewöhnungssache. Mir fällts programmatisch halt einfacher. Das liegt aber eher daran, dass ich XML nicht gerne schreibe, weil s.u.
viel schlimmer bei der xml-hell find ich den nervtötenden Zwang wirklich alles via XML konfigurieren zu wollen... - aber bei klassischem Markup sehe ich dann doch Vorteile.
Ich finde XML einfach generell unschön, wenn mans händisch schreiben muss. Es gibt zuviel unnötige Tipparbeit. Warum muss man beim schließen eines Tags den Namen des Tags nochmal mitgeben? Und warum überhaupt diese nervigen <, > und / Sonderzeichen? Geschweifte Klammern ist doch jeder gewöhnt!
Zur Spring-XML-Unterstützung... okay - das hatte ich nicht getestet, dann ist das Spring-Plugin-Projekt halt besser, als das normale XML-Editor-Projekt... - aber der Eclipse-XML-Editor ist sowieso der letzte Grütz! und somit auch die Verbindung mit dem Hibernate-Kram... und das Hibernate-Plugin ist bei dem Editor auch eher unbrauchbar... obwohl ich jetzt immerhin die DB-Connection hinbekommen hab.
Naja, Refactoring kann der XML-Editor perse ja nicht unterstützen. Woher soll er wissen, welche Attribute z.B. auf Klassen oder Member gemappt sind? Er kann nur maximal das unterstützen, was die DTD oder das XML-Schema hergibt und da kannst Du sowas ja nicht definieren. Wenn Du also in der XML Content Assist auf Java-Klassen oder die DB haben willst bzw. einen Hook ins Refactoring haben willst, dann muss das über ein spezielles Plugin gelöst werden. Spring IDE und Hibernate Tools finde ich da eigentlich ziemlich brauchbar. Ich kann da gut mit arbeiten.
ja - nur bieten die hibernate-tools ja genau das refactoring ja nicht... - und zwar kann ich inzwischen mein DB-Schema via Hibernate-Plugin ansprechen - aber code-assist für Tabellennamen oder Spalten hab ich immer noch nicht.
Klar kann xml das per se nicht... - aber eigentlich könnte er mir zumindest file-names bzw. full-qualified-names in non-java-files wie er es ja so schön angibt versuchen zu ersetzen - soll er halt alle textdateien in meinem workspace durchsuchen... ich will es so
und xml schreiben.. wenn wie gesagt das code-assist gut ist, dann muss man zumindest das end-tag nie mehr schreiben... - IDEA erkennt auch automatisch, wenn man so ein Tag hat: <Tag /> und das mit /> zumacht und entfernt das zugehörige dahinterstehende </Tag> ... das ist im eclipse-editor auch immer nervig. Also liebe IDE-Hersteller... werdet da drin einfach besser... - wenn man Java-Code ständig komplett selber schreiben würde, dann würde heute auch niemand mehr Java schreiben - ich sag nur getter/setter oder equals/hashcode Methoden bei großen Pojos - das wäre doch schier Wahnsinn
ja - nur bieten die hibernate-tools ja genau das refactoring ja nicht... - und zwar kann ich inzwischen mein DB-Schema via Hibernate-Plugin ansprechen - aber code-assist für Tabellennamen oder Spalten hab ich immer noch nicht.
War mir da jetzt nicht so sicher, da ich ja keine hbms schreibe, weil ich Annotations nutze. Aber stimmt schon: Bei der cfg hat er beim Mapping der Klassen auch weder Content Assist noch Refactoring. Das ist unschön, liegt aber nicht an Eclipse sondern an den Plugin-Machern.
Darauf wollte ich halt hinaus: Das Dilemma bei Eclipse ist einfach, dass viele Third-Party-Plugins nicht so gut sind wie die kommerzielle Konkurrenz. In diesem Fall hat es JBoss verbockt.
Klar kann xml das per se nicht... - aber eigentlich könnte er mir zumindest file-names bzw. full-qualified-names in non-java-files wie er es ja so schön angibt versuchen zu ersetzen - soll er halt alle textdateien in meinem workspace durchsuchen... ich will es so
Möglich ist es, das ist ja nicht der Punkt. Gibt ja durchaus Eclipse Plugins, wo Content Assist und Refactoring in XML-Configs funktioniert (siehe Spring IDE).
Aber wie gesagt: das ist Sache der Plugin-Entwickler und liegt nicht an der (Core) Eclipse IDE. Natürlich fällt es negativ auf die IDE zurück, wenn manche Plugins keine gute Usability haben.
und xml schreiben.. wenn wie gesagt das code-assist gut ist, dann muss man zumindest das end-tag nie mehr schreiben... - IDEA erkennt auch automatisch, wenn man so ein Tag hat: <Tag /> und das mit /> zumacht und entfernt das zugehörige dahinterstehende </Tag> ... das ist im eclipse-editor auch immer nervig. Also liebe IDE-Hersteller... werdet da drin einfach besser... - wenn man Java-Code ständig komplett selber schreiben würde, dann würde heute auch niemand mehr Java schreiben - ich sag nur getter/setter oder equals/hashcode Methoden bei großen Pojos - das wäre doch schier Wahnsinn
Jup das stimmt. Fast jede Sprache ist nichts ohne ihre IDEs. Aber so schlecht ist der XML-Editor von Eclipse nun auch nicht. Einzig der JSP-Validator ist ziemlich Grütze.
nur der JSP-Validator? Bei sämtlichen xml-dokumenten hakts mitunter gewaltig... - die ganze IDE hakt manchmal doch gewaltig - aber das ist nen anderes Thema
letztlich hat man imho bei Eclipse vergessen wesentliche Entwickler-Probleme zu bearbeiten, wohingegen man mehr Gehirnschmalz in Richtung Plug-In Design, SWT oder auch Osgi gesteckt hat - was ja gut ist und war - aber jetzt hätt ich doch ganz gerne mal wieder mehr Entwicklungen in Richtung eigentlicher Grundfunktion - eine IDE für Java bitte ... ansonsten kann ich natürlich auch IDEA nutzen - aber das geht ja numal bei so manchem nicht, insb. weil IDEA Geld kostet oder der Kunde das nicht will.
Aber es ist natürlich richtig, dass die Plug-In Macher dann Schuld haben an der Misere - aber wenn XML nunmal ein zentraler Bestandteil heutiger Programmierarbeit ist, dann will ich natürlich durch die IDE bestmöglichst unterstützt werden.. und seit 3 Jahren sehe ich beim XML-Editor nicht wirklich ne Entwicklung... auch der Schemaeditor verhält sich manchmal etwas merkwürdig...
nur der JSP-Validator? Bei sämtlichen xml-dokumenten hakts mitunter gewaltig... - die ganze IDE hakt manchmal doch gewaltig - aber das ist nen anderes Thema
Die Core Java IDE läuft imo ziemlich rund. Du bist halt Webentwickler und da hingt WTP halt ziemlich hinterher. Aber da sind wir wieder bei der Plugin-Entwicklung.
Ich gebe Dir grundsätzlich schon recht. Der Entwickler hat nicht viel davon, wenn die Core IDE zwar gut läuft, einzelne Plugins aber Macken haben, die für die Entwicklung unerlässlich sind. Deshalb sollten sie tunlichst sehen, dass sie die Webtools mal up-to-date kriegen, denn J2EE ist ja mittlerweile schon der wichtigste Teil von Java geworden.
Bei serverseitigen Frameworks wie ZK oder Echo2 gibt es diese Trennung nicht. Dort schreibt man Code der am Server läuft - man hat auf alle Javaresourcen ohne Umwege Zugriff. Das Framework kümmert sich darum, dass die die Browser-GUI und den Serverkomponeten zu syncronisieren.
Terminator hat gesagt.:
> RAM
Also wenn der Client Teil in Java geschrieben wird, dann wird doch bestimmt ähnlich wie bei JSF ein serverseitiger KomponentenTree oder hier dann vielleicht ein NodeTree aufgebaut.
Wenn der State dieses Tree beim Response für Änderungen zur Verfügung stehen muss, wird auch bei dieser Technik der Tree in Session oder wenn vorhanden in Page Scope gespeichert.
=> braucht genauso viel RAM
(Ausnahme wäre komplette Serialisierung des Trees zum Client)
Ich kenne jetzt die Treekomponente von GWT nicht, aber bei GWT kannst du das auch ohne Sessiondaten abwickeln. Der Speichervorteil für GWT ergibt sich daraus, dass es kein Gegenstück aller GUI-Komponenten am Server geben muss. Die Serverseite muss hier nur Daten liefern - was nebenbei auch ein Sicherheitsproble sein kann.
Große Tree's sind auch bei serverseitigen Lösungen kein Problem - wenn sie nachgeladen werden. (z.B. >> dieser << Tree hat in der DB über 13.000 Einträge,
gehalten werden server- und clientseitig nur die angezeigten, nachgeladen wird beim Öffnen einer Node.
Terminator hat gesagt.:
> Databinding und MVEL
Sorry kenn ich nicht.
Was bringt das denn an Performance bei DB-Lastigen-Apps gegenüber JDBC?
Performance bringt das nicht - eher mehr Komfort. Mit dem Databindung sollten die GUI-Felder automatisch, sprich ohne Zweisungorgien, von den Beans, welche die Daten halten, beschickt werden und umgekehrt. Oft sind das Domainbeans einer Perstenzschicht, können aber aber Beans von Webservices usw. sein.
Unabhängig von der Lösung, läuft es darauf hinaus, dass die GUI direkt von Daten in den Beans befüllt wird und ev. auch wieder zurück. Hier hakt es dann schon mal bei JDBC. Da gibt es keine keine entsprechende Javaklasse. Die meisten Frameworks gehen beim Databinding (mit einer DB) von einem vorhandenen Persistenzframework (EJB, Hibernate, iBatis) aus. Da kann man dann aber recht elegante sachen machen, z.B.
Code:
<label value="@{controller.auftrag.kunde.name}">
Hier wird einem das Querlesen erspart, vom Auftrag zum Kundensatz daraus den (Kunden)namen. Der Controller (bei JSF auch managed Bean genannt) muss den Bean via getAuftrag bereitstellen. Bei Listen stellt der Controller meist die Manager/DAO bereit z.B. auftragDAO...
Bei den Expression Languages (EL, MVEL) arbeiten ähnlich können aber auch Resourcen außerhalb des Controllers "anzapfen" - z.B. Objekte vom Springframework.
Hier noch ein aktuelles Beispiel von mir, hier habe ich einen JDBC-Evaluator geschrieben. Damit kann man seine Prompter, Listen... direkt von der Datenbank zapfen - ohne Persitenzschicht dazwischen.
Der Layoutmanager von ExtJS wurde bereits eingebunden, siehe >> hier <<. Für meinen Bedarf finde ich das ZK Layout ausrreichend. Es gibt schon jetzt einige Anbindungen von externen Ajax-Komponenten (FCKEditor, GoogleMaps, Timeline, ExtJS Layouter) es werden sicher noch mehr.
Terminator hat gesagt.:
Konzept klingt eigentlich ganz gut, meiner Meinung ist das ähnlich JSF.
Die Idee ist sicher bei beiden Frameworks die gleiche. Die Komponenten von ZK sind meiner Meinung nach mächtiger und bringen AJAX gleich mit. Die Lernkurve bei ZK ist wesentlich flacher als JSF. Die GUI-Definitionen bei ZK kommen meistens mit der Hälfte der Zeilen/Zeichen der JSF-Lösung aus.
Terminator hat gesagt.:
Schätz mal bei ZK wird der Vorteil sein, dass Commuikation/Datenaustausch zw. Client/ClientKompos und Server/ServerKompos schon absolut automatisiert sind.
Genau. Wie du am oberen JDBC-Beispiel schon gesehen hast. Ich fülle meine Combobox aus der Datenbank und habe null Arbeit mit dem Transfer in den Browser. Ein Schlüsselwort dazu und die Combobox wird erst beim Öffnen (via Ajax) dynamisch nachgeladen.
Code:
<combobox .. fullfill="onOpen"...
Das Schöne bei ZK ist, dass es zwar ganz interessant ist sich auszukennen, aber für die Erstellung von Web/Ajax-Wendungen nichts von Ajax, Javascript, Server- oder Clientseite wissen muss. Man schreibt Anwendungen im Desktop-Stil und das Framework macht den Rest (vor allem die Darstellung auf den verschiedenen Browsern!!!).
Terminator hat gesagt.:
Ich finde den Java-Code viel eleganter als die XML-Hell. icon_wink.gif Ich weiss nicht welche IDE Du benutzt, aber beispielsweise in Eclipse ist der XML-Editor eher schlecht. Was passiert, wenn Du Refactoring im Controller machst - z.b. die save-Methode umbenennst? Gibts für ZK ein hübscher Plugin oder musst Du die XML dann von Hand anpassen?
Das Eclipse-Plugin hält noch bei 0.5.2, der GUI-Designer ist noch extra, ein kommerzielles Tool noch in Arbeit. Also von Seite gibt zum Refactoring noch keine Hilfe. Aber wie schon gesagt, da scheiden sich die Geister. Bei den Vorteilen schließe ich mich SnooP's Ausführungen (Hierachie) an. Die XML Lösung dürfte auch etwas weniger Code sein.
Endlich mal jemand, der nicht verblendet ist. :applaus:
ExtJS ist recht nett und mit FF3 auch erstaunlich schnell, aber was davon brauch ich wirklich für eine Anwendung?
Die knuffigen fade/slide/transparent,... Komponenten mit schlagschatten hängen mir schon zum Hals raus.
Jaja ich weiß, das kannste alles ausknipsen, anpassen, etc. Manchmal ist weniger aber doch Mehr.
Mich würden mal solche Komponenten interessieren:
- PDF Exporter Klassen für Grids & Forms (ohne ein zusätzliches Layout anlegen zu müssen)
- integrierte Quickfilter für Grids
- oder Netz-Graph-View Panels mit Auto-Layout
Und was die Performanz angeht, nach meinen Erfahrungen sind 100 Rows etwa die Schmerzgrenze. Da gibt es aber starke Unterschiede.
