nicht angemeldet
Hi Christoph,
Das ist (unter anderem) das, was ich nicht verstehe. Ich bin ein großer Freund von "gut geplanten Entwicklungsprozessen", aber ich sehe noch nicht, welche Vorteile JSP da gegenüber anderen Techniken bietet.
Was wären die 'anderen Techniken'? Alle prinzipiell verwendbaren? Alle vergleichbaren? Alle für ein konkretes Projekt theoretisch verwendbaren? Solche, die sich bei einem konkreten Projekt anbieten, weil sie sich 'relativ einfach' in eine existierende Server-/IT-Infrastruktur intergieren lassen ? etc.
Solche Vergleiche abstrakt anzustellen, ist schwierig und wahrscheinlich wenig sinnvoll, aber dennoch zwei der solchen (unter Berücksichtigung, dass ich die 'anderen' vergleichbaren Techniken kaum kenne bzw. nicht auf dem neuesten Stand evtl. vorhandener Erweiterungen bin. Daher: Korrekturen sind höchst willkommen):
JSP vs. ASP: JSP funktioniert auf allen Java-Plattformen, ASP nur auf MS-Plattformen
JSP vs. PHP: Schenken sich funktional im Prinzip nichts (habe hier allerdings ein paarmal von 'schweren' Sicherheitslücken in bestimmten PHPP-Versionen gelesen)
Also:
- Soll eine Web-Applikation from Scratch entwickelt werden und es gibt kundenseitig keinerlei technische Vorgaben und 'wir' bekommen für eine PHP-basierte Lösung den Zuschlag, dann machen wir es mit PHP.
- Soll eine Web-Applikation from Scratch entwickelt werden und es gibt kundenseitig keinerlei technische Vorgaben, 'wir' können 'aber nur' Java und bekommen für eine Java-basierte Lösung dennoch den Zuschlag, dann machen wir es mit Java/JSP.
- Soll eine Java-basierte Enterprise-Applikation zu einer Web-Applikation erweitert werden, dann verwendet man sinnvollerweise JSP.
Und so weiter und so fort...
Nochmal zu JSPs: Eine konsequente Trennung von Entwicklung und 'Webdesign' ist durch Vewendung von Taglibs (JSP-Tags) möglich. Das bedeutet, 'Webdesigner' können auf Präsentationselemente, hinter welchen sich komplexeste Logik verbergen kann, einfach durch XML-Syntax zurückgreifen. Aus Designersicht würde sich zur HTML-Referenz dann eine Taglib-Referenz gesellen.
Beispiel:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML>
<HEAD>
<%@ taglib uri="customer-taglib.tld" prefix="cjsp" %>
<TITLE><cjsp:name /></TITLE>
<LINK REL=STYLESHEET
HREF="JSP-Styles.css"
TYPE="text/css">
</HEAD>
<BODY>
<H1><cjsp:fullname /></H1>
<cjsp:orders />
</BODY>
</HTML>
Diese Beispiel-Code könnte bewirken, dass alle Auftragsdaten eines bestimmten Kunden in der resultierenden HTML-Seite dargestellt werden. Welche Logik dazu notwendig ist (Datenbankzugriffe, Securitiy etc), ist für den 'Designer' irrelevant.
Ant - der Beschreibugnstext trifft es schon ganz gut: "Apache Ant is a Java-based build tool. In theory, it is kind of like Make, but without Make's wrinkles."
Eben: "in theory it is ..." - wie setze ich das jetzt in irgendeine Praxis um?
Indem Du in der Dokumentation nachliest ('Running Ant')?
Kurz zum Prinzip: Ant führt Tasks durch, die in einem XML-File ('build-file') als 'targets' definiert werden. Diese 'targets' können mit Hilfe des Attributes 'depends' miteinander verkettet werden, so dass man faktisch Ant auch als einen Batch-Interpreter auffassen kann.
Beispiel 'Kompilieren/Testen einer Applikation:
Logische Schritte könnten sein:
1. Vorbereiten des Dateisystems -> Erstellen eines Build-Verzeichnisses, evtl. mit Unterverzeicchnissen (wenn schon existent, dieses erst löschen) = target 'prepare'
<target name="prepare">
<mkdir dir="${project.build.dir}*******" />
</target>
2. Kompilieren aller Java-Sourcen in build/classes (instanziiere dazu eine weitere VM, aber breche bei einem Fehler _nicht_ ab) = target 'compile'
<target name="compile" depends="prepare">
<javac srcdir="${project.src.dir}" destdir="${project.build.dir}/classes" debug="off" failonerror="false">
<pathelement path="${java.class.path}"/>
<pathelement path="${Pfad zu weiteren notwendigen classes/jars}"/>
</javac>
</target>
3. Kopiere alle Resourcen, die für die Unit-Tests benötigt werden, in ein entsprechendes Unterverzeichnis von build (und setze, wenn notwendig, den CLASSPATH entsprechend) = target 'test.prepare'
<target name="test.prepare" depends="compile">
<copy todir="${project.build.dir}/resrc">
<fileset dir="${project.resrc.dir}">
<exclude name="irgendeinUnterverzeichnis/irgendeinDateiname.*" /><!-- aber kopiere keine Datei dieses Namens unabhängig der Extension, die in irgendeinUnterverzeichnis liegt -->
<exclude name="**/*.doc" /><!-- und kopiere überhaupt keine Word-Dokumente -->
</fileset>
</copy>
</target>
4. Lasse die Tests laufen = target 'test.run'
<target name="test.run" depends="test.prepare">
<java classname="de.mein-package.TestRunner" fork="true">
<classpath>
<pathelement path="${java.class.path}"/>
<pathelement path="${project.build.dir}/classes"/>
<pathelement path="${Pfad zu weiteren notwendigen classes/jars}"/>
</classpath>
</java>
</target>
5. Kopiere alle JSPs der Webapplikation in ein entsprechendes Unterverzeichnis von build = target 'jsp.prepare'
weitere Beispiele erspare ich mir nun....
6. Prüfe. ob die JSPs syntaktisch korrekt sind. Dazu 'kompiliere' die JSPs in Java-Servlets (Jasper-Compiler) und diese anschließend in Bytecode = target 'jsp.compile'
In den Build-Files können Variablen definiert werden ('property'), die wiederum andere refenzieren können (expansion). Im Idealfalle (dem man eigentlich recht schnell nahe kommt) können die Target-Definitionen so allgemein halten kann, dass man sie für fast jedes Projekt vewenden kann. Man muss nur jeweils die 'properties' anpassen (Pfade der Sourcen, Resourcen, Build-Verzeichnisse etc.). Selbst diese muss man im Build-File nicht unbedingt anpassen, da die Werte auch aus Umgebungsvariablen ausgelesen werden können, und die projektspezifische Anpassung dadurch in eine userconfig.bat oder userconfig.sh verlagert werden kann, was m. E. noch einfacher/übersichtlicher ist.
Properties******* (müssen _vor_ den Targets deklariert werden!):
<property name="project.home" value="${env.PROJECT_HOME}" /> <!-- aus Umgebungsvariable lesen -->
<property name="project.build.dir" value="${project.home}/build" />
<property name="project.src.dir" value="${project.home}/src" />
<property name="project.resrc.dir" value="${project.home}/resrc" />
ein Aufruf 'build test.run' in der Konsole führt somit zur seriellen Abarbeitung der Schritte 1-4.
Ich weiß, es ist nicht immer leicht, da den Überblick zu behalten
Ich kann bedauerlicherweise keinen Überblick "behalten", weil ich - was Tomcat angeht (und _nicht_ den Apache-HTTP-Server) - noch nie irgendwelchen Überblick hatte :-(
Nun ja, wie Simon schon sagte, Tomcat ist die Referenzimplentierung bestimmter APIs (ein Servlet-Container, der JSP-Technologie untersützt). Tomcat ist auch ein Standalone-Webserver, kann aber genauso zusammen mit Apache betrieben werden (Verbindung über HttpConnectoren, siehe TOMCAT_HOME/conf/server.xml). Was _genau_ ist Dir denn unklar?
Viele Grüße,
Martin Jung