Lotus Notes / Domino Sonstiges > Java und .NET mit Notes/Domino

Java Web Frameworks

(1/7) > >>

flaite:
Fing alles mal mit Struts an. Das ist jetzt aber überholt. Es gibt ein paar neue und nicht mehr ganz so neue.
Ich werde hier über JSF, wicket und struts2 berichten. Die wirken am vielversprechendsten.
Alle haben ihre Stärken und Schwächen. Man muß wohl pro Projekt entscheiden.
Ich prüf die alle als Webfrontends für mein Börsenspiel.

1. JSF (präferiere apache.jakarta myfaces und facelets)
+ gute Dokumentation, gute Bücher, viele user generated content im Internet, alles gut googlebar. 
+ Komponentenmarkt, wobei das alles nicht so einfach ist. Oracle hat apache seine adf-Komponenten geschenkt. Das sind zusätzliche Sachen, die man myFaces beigeben kann. Unter apache-Flagge heissen diese Zusatzkomponenten Trinidad. Soll sehr ausgereift sein. Ich halte das aber bis auf weiteres für nicht einfach. Gibt auch ajax-Komponenten (z.B. IceFaces). Man braucht da gar nicht javaScript programmieren. Die Ajax-Magic ist in den Komponenten. Jedoch kann die Integration teilweise recht komplex werden. Hab das sowieso noch gar nicht ausprobiert und bin eher mit den Basis-Komponenten unterwegs. Und ich hatte z.B. mit der Integration von facelets mit ein paar Tomahawk-Komponenten bei gegebenen Zeitrahmen für mich unlösbare Probleme.
+ irgendwie recht übersichtlich. Man definiert in einer faces-config.xml Navigationspfade, Validierer, Konvertierer, "Aktionen" (heissen Backing-Beans). Zum Zurechtfinden ist das besser als jede Doku.
+ Facelets hat einen absoluten brauchbaren Templating-Mechanismus. Man kann ein Template für direkt mehrere Seiten definieren. Z.B: Links ist der Navigationsbereich. Oben ein Header. Unten ein Footer und in der Mitte der Hauptbereich. Oder beliebig anders. Spezialisierte Html Designer können damit klarkommen.
+ wie überall in Java gute Unterstützung für Internationalisierung und Lokalisierung.
+ wirklich gute Integration mit Spring.
+ JBoss hat ein eigenes sehr interessantes Framework namens SEAM, um JSF mit EJB3 oder normalen Backend-POJOS zu verbinden.
+ Gibt einen guten Toolsupport. Ich mach aber erstmal ohne. Oft verwirrt das nämlich eher, wenn man sich noch nicht so gut mit einer Technologie auskennt.
+ JSF wird eine gute Zukunft vorausgesagt. Wohl v.a. auch wegen der Übersichtlichkeit. Das verspricht für Anwenderorganisationen leichte Erweiterbarkeit, Wartung, etc. und dem Komponentenmarkt, wobei auf diesem Markt vieles sowieso openSource ist.
+ oft sind die Fehlermeldungen ziemlich klar. Vor allem mit Facelets.

- wohl nicht geeignet für Seiten mit sehr viel Traffic. Es wird da so einiges in der Http-Session abgelegt und das skalliert dann zwangsläufig nicht so gut bei steigenden Anwenderpopulationen.
- Manche Sachen sind einfach kurios. Wenn man z.B. nicht ein paar Workarounds benutzt, stimmt die URL im Browser nicht mit der dargestellten Seite überein. Manche JSF-aficionados finden das nicht so schlimm. Ich schon. Gibt zwar workarounds, mir sind aber deren Nachteile noch nicht zur Gänze klar.
Oder sowas hier: http://sfjsf.blogspot.com/2006/03/usings-sets-with-uidata.html (hat mich 2 Stunden gekostet).
- Es gibt ein paar Kompatibilitäts-gotchas zwischen den benutzten Technologien, die mich ganz schön ins Schwitzen bringen. Google hilft oft.
- Backbutton ist problematisch. Das ist leider oft so. SEAM behauptet, es gelöst zu haben.
- Gibt zwar eine Menge Komponenten, die definitiv einiges leisten. Bisher hat das ausgereicht. Wenn nicht, muß man wohl selber tief da reingehen. Eine JSF-Komponente hat 7 Lebenszyklus-Schritte pro Aufruf. Das ist sicher nicht einfach.
- Anfänger sollten das imho nicht als erstes Java Web Framework nehmen. Default-mässig ist da JSP als Basis für die View. Das war mir - wie sehr sehr vielen - zu frustrierend. Zukünftige Versionen sollen JSF freundlicher werden. Wenn man sich mit Model View Controller und Schichten-Architekturen nicht so auskennt, kann es leicht zu einem Chaos-Design verleiten, auf das man nach einer Woche keinen Bock mehr hat.

flaite:
Java Server Faces (JSF) ist nix, wovor man Angst zu haben braucht. Der Test für meinen Börsenhandelsplatz verläuft soweit überzeugend. Gut. Es gab Momente, in denen ich eine Menge Wasser geschluckt habe. Mittels google konnte ich aber immer eine Lösung finden. JSF ist einfach zu bedienen, im innern aber schon ziemlich komplex. Es mag sein, dass es Anwendungsfälle gibt, für die man tief in das Framework einsteigen muss und das wird bestimmt leicht komplex. Für die Börsenplattform reichts aber und das ist ein gutes Zeichen, weil Hello World ist das auch nicht. Ich werd den code irgendwann auf google code posten, falls jemand Interesse hat.
Eine gute Zusammenfassung einiger dunklen Gassen von JSF, denen ich auch begegnet bin, findet sich hier: http://typo.ars-subtilior.com/articles/tag/jsf
Die beiden guten Bücher sind oben genannt.

Integration mit Backendframeworks
Spring als Backendframework ist gut integrierbar. JSF arbeitet in seinen Backing Beans mit dem vom Spring massiv popularisierten dependency injection. Spring integriert JSF auch von sich aus so gut, dass
a) Spring Beans in Backing Beans deklarativ dependency injected werden können! und
b) Spring Beans sogar direkt als Backing Beans deklariert werden können.
Auch EJB3 lässt sich offenbar gut integrieren, wobei ich das noch nicht ausprobiert habe. Für JBoss gibts sogar mit SEAM ein extra Framework zur Integration von JSF mit EJB3 oder Pojos (Plain Old Java Objects). SEAM sieht sehr vielversprechend aus und erzeugt eine Menge Interesse.

Jedenfalls hat das für mich Lust gemacht weitere, reichhaltigere JSF Komponenten Frameworks kennenzulernen (ADF Faces/Trinidad, ICEFaces oder auch sowas wie ajax4jsf).

Mit entsprechender Literatur kann imho ein Junior Java Programmierer in 4 Wochen ein absolut brauchbarer JSF Designer werden, ohne dass es in Stress ausarten muss. Bei einem Projekt sollte aber ein erfahrener Java Architekt dabei sein, der sich umfassend mit Schichtenarchitektur, dem verwendeten Server, Webentwicklung und allgemein auskennt.

Gruß Axel

Mark³:
ich bastel gerade mit ZK rum (http://www.zkoss.org Da hat man schnell eine schicke AJAX-Webgui hingebastelt. Allerdings die Integration mit Hibernate und anderen Sachen muss man selbst übernehmen (Habe noch nie mit Hibernate gearbeitet, will aber natürlich keine DB-Zugriffsschicht selbst basteln)

Werde nochmal JBoss SEAM kurz beleuchten und dann eins dieser Dinge nehmen, um die grausame Webentwicklung in Notes loszuwerden. Ich habe zwar in Notes auch AJAX-Sachen mit Prototype und Scriptaculous gebaut, aber das ist mir echt zu unübersichtlich: Die Logik ist verstreut in js-Libs, Forms, Agents, Pages, Subforms, Passthrough-HTML, da blick ich durch meine eigenen DBs nicht mehr durch.

flaite:
Wolltest Du nicht Spring und Hibernate machen? Seam ist hauptsächlich für die Integration von JSF mit Hibernate3.
Am wichtigsten sind aus meiner Sicht die Basics. Versteht nur vielleicht jeder was anderes drunter.
Hab leider auch bei der Java Entwicklung erlebt, wie da fröhlich losgehackert wird und ohne Archtitektur endet das in einem noch größeren Chaos als Notes-Entwicklung.
Einen realistischen Schnelleinstieg liefert das Praxisbuch "Spring & Hibernate".

Ich bin jedenfalls aktuell Anhänger eines geschichteten kontrollierten POJO-mit-Spring Ansatz mit  JSF als Frontend und Hibernate für Datenbank Zugriffe. The greater picture.
Dabei kann ich JSF mit Struts2 oder whatever austauschen.
Dabei kann ich Hibernate mit IBatis SQL Maps oder Spring JDBC austauschen.
Wenn es nötig ist, kann ich zumindest in meiner Lieblings-DB Posgres problemlos stored procedures schreiben. Wenn ich das in Posgres beherrsche, ist der Schritt zu Oracle oder DB2 stored procedures klein. 
Aus meiner Praxis haben sich die folgenden Dinge als wichtig herausgestellt (viel wichtiger als Ajax Features oder das zufällig verwendete Framework):
- Schichtenarchitektur: Web-Schicht -> Service Schicht -> DAO Schicht und ein Domain Model mit gettern und settern, obwohl das überhaupt nicht OO ist.
- die benutzte Datenbank gut beherrschen.
- das Webframework bis zum best practice level beherrschen. (z.Zt. JSF und da hab ich am Anfang vieles nicht richtig verstanden).
- Integrations- und Unittests für alle Schichten. In Spring gibts für Integrationstests interessante Junit-Erweiterungen.
- Spring in einem hohen Grade verstehen (inkl. AOP Basics, verschiedene Bean Wiring Methoden, Aufteilung der application.xml auf verschiedene xml Dateien im Namen der Übersichtlichkeit, Bean Factories, Transactions, Spring im Web).
- Hibernate in einem hohen Grade verstehen (das ist das schwierigste: Inkl. Fetching Strategien, 1-n, n-1, m-n mappings, lazy loading, optimistic und pessimistic locking, caching, business keys in equals/hackcode Methoden für die Business Objekte).

Das ist ein völlig anderes Entwicklungs-Modell als mit Lotus Notes, aber sehr effektiv.
Diese Plattformen werden sehr viel benutzt und sind meiner Meinung nach eher noch bug-freier als Lotus Domino. Das Problem sitzt damit eher vor dem Bildschirm und v.a. die Hibernate Foren sind voll von Entwicklern, die immer die gleichen Fehler machen. Das sagt natürlich auch, dass es relativ einfach ist, in die Fallen zu tappsen.

Die Richtung stimmt aber. Zeigt allein schon, dass EJB3 soooo viel Hibernate und Spring ähnliche Features besitzt. Die Exit-Strategie ist also da. IBM seitig wird Websphere irgendwann auf EJB3 gehen müssen. Ich bin 2003 auf Javaranch von einem hohen IBM Websphere Architekten ziemlich massiv geflamed worden, als ich mich sehr positiv über Spring oder genauer über Rod Johnsons erstes Buch ausgesprochen habe. Unzählige negative Äusserungen von Rod Johnson über Websphere später, gibt es nun eine immer stärkere Zusammenarbeit zwischen den Websphere Classic Leuten und Spring. Viele Artikel von internen Autoren (keine extern gekauften), IBM Vortragende auf Spring.One Konferenz, Zusammenarbeit um Spring auf Websphere zu "zertifizieren".

Mark³:
Spring und Hibernate steht auch noch auf der Liste. Momentan bin ich kurz davor, über eine ZK-GUI einen Datensatz mit Hibernate (auf MySQL) zu erzeugen. Wie immer gab es Myriaden fehlende Pfade zu irgendwelchen XML-Dateien etc aber ich nähere mich.
Einen CurrentSessionContext habe ich auch nicht, da muss ich momentan erstmal eine Session mit openSession aufmachen, alles mui komplex. Aber nun habe ich es geschafft, ein paar Datensätze anzulegen:

--- Code: ---<window title="Registration" border="normal">
        <zscript>{
            import zutritt.model.Person;
            import util.HibernateUtil;
            import org.hibernate.Session;
            import org.hibernate.*;
                void submit() {
               
                        Person person = new Person();
       
                        person.setSmtpMail(email.value);
                        person.setFirstName(forename.value);
                        person.setLastName(surename.value);
                        person.setEmpNumber("12345678");
                        person.setCostCenter(cc.value);
                        try {
                        Session session = HibernateUtil.getSessionFactory().openSession();
Transaction tx = session.beginTransaction();
session.saveOrUpdate(person);
tx.commit();
session.close();
HibernateUtil.getSessionFactory().close();
                        }catch (Exception e) {
                        e.printStackTrace();
                                alert(e.getMessage());
                        }
                }               
        }
        </zscript>
        <grid>
        <rows>
                <row>Name : <textbox id="forename" value="Hans" /></row>
                <row>Surename : <textbox id="surename"  value="Meier" /></row>
                <row>Login Name : <textbox id="nickname" /></row>
                <row>Email: <textbox id="email" value="a@b.cd" /></row>
<row>Costcenter : <textbox id="cc" value="DE61000327"></textbox></row>
                <row><button label="submit" onClick="submit()"/></row>
        </rows>
        </grid>
</window>

--- Ende Code ---


--- Code: ---<?xml version="1.0"?>
<!DOCTYPE hibernate-mapping PUBLIC
"-//Hibernate/Hibernate Mapping DTD 3.0//EN"
"http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd">
<hibernate-mapping package="zutritt.model">
  <class name="Person" table="PERSON">
  <id name="id" type="long" column="person_id" unsaved-value="0">
<generator class="identity"/>
</id>
        <property name="smtpMail"  column="SMTPMAIL"/>
        <property name="firstName" column="FIRST_NAME"/>
<property name="lastName" column="LAST_NAME"/>
  <property name="empNumber"  column="EMP_NUMBER" />
<property name="notesMail"  column="NOTESMAIL" />
<property name="costCenter"  column="COSTCENTER" />
  </class>
</hibernate-mapping>
--- Ende Code ---

Navigation

[0] Themen-Index

[#] Nächste Seite