nicht angemeldet
unterschied jsp / php
hallo alle zusammen,
ich habe mir gerade mal ein bißchen was zu java server pages durchgelesen...
ich beherrsche ein wenig php, und was mir dabei aufgefallen ist:
kann es sein, daß zwischen php und jsp gar kein sooo großer unterschied besteht?
ich meine, klar, beide generieren letzten endes html-seiten,
aber selbst der weg dahin sieht bei beiden ähnlich aus?
ich meine, beide scheinen letzten endes in statischen html-code eigebettet zu sein ? lediglich die die syntax scheint sich zu unterscheiden....?
und wenn ich das richtig verstanden habe, sind auch servlets nicht so das wahre?
kann mir vielleicht jemand in ein, zwei sätzen mal den unterschied zwischen php und jsp oder servlets erläutern?
bin mir nicht so sicher, ob ich das alles richtig verstanden habe...
was ist denn "besser", bzw. für einen bestimmten zweck besser geeeignet? wann setze ich jsp oder servlets ein, und wann php? oder kann php sowiso alles, was jsp und servlets auch können?
vielen dank, falls sich jemand bereit erklärt, mir da n bißchen auf die sprünge zu helfen...
grüße,
klaus
-
Hallo Klaus,
kann es sein, daß zwischen php und jsp gar kein sooo
großer unterschied besteht?Doch, er ist :)
Die zugrunde liegende Idee ist eine komplett andere. PHP
wurde als HTML-Preprozessor entwickelt, waehrend es die Idee
von JSP war, eine Art Template-Engine zu entwickeln.
Letztenendes ist die Idee, die hinter Servlets und JSP sitzt,
die, dass man die 'Business Logic' -- also der Teil des
Programms, der bestehende Daten abfragen, veraendern und
beeinflussen kann -- ueber Servlets bedient wird und dann die
Daten in Form von Beans in den JSP-Seiten zur Verfuegung
gestellt wird. Man erhofft sich dadurch eine komplette
Unabhaengigkeit zwischen Design und Software-Architektur.
Durch verschiedene Frameworks (z. B. das Struts-Framework)
kriegt man das sogar erstaunlich gut hin :)Auf hochdeutsch heisst das: es gibt keine Programmlogik in
JSP-Seiten, nur der Code, der die Ausgabe generiert, steht da
drin. Saemtliche Programmlogik ist auf die Servlets verteilt.und wenn ich das richtig verstanden habe, sind auch
servlets nicht so das wahre?IMHO ist diese gesamte Java-Architektur sehr langsam und
haeufig auch inkonsistent. Meine 128MB RAM reichen zur
Entwicklung auf keinen Fall... unter einem Gigabyte sollte
man da nicht anfangen.Gruesse,
CK-
Hallo,
Auf hochdeutsch heisst das: es gibt keine Programmlogik in
JSP-Seiten, nur der Code, der die Ausgabe generiert, steht da
drin. Saemtliche Programmlogik ist auf die Servlets verteilt.Wenn man benutzerdefinierte Tags (Custom Tags -> Taglibs) verwendet,
ist überhaupt kein Java-Code mehr in der JSP-Datei notwendig. Statt
irgendwelchen Bean-Aufrufen stehen dann nur noch spezialisierte Tags
in der JSP-Datei, die genau wie normale HTML-Tags aussehen und sich
auch so verhalten (sollten).
Das hat natürlich den Vorteil, daß auch Personen ganz ohne jede
Java-Kenntnis solche JSP-Dateien verstehen, erstellen und warten
können. Zusätzlich bleibt die Funktionalität von der Präsentation
getrennt. Wenn man es richtig anstellt - und das ist nicht wirklich
schwer - kann noch dazu jede HTML-Generierung/Ausgabe aus dem
Java-Code der Tags verbannen, was bei Beans meist nicht möglich ist.
(Mit den Frameworks kenne ich mich nicht aus.)und wenn ich das richtig verstanden habe, sind auch
servlets nicht so das wahre?IMHO ist diese gesamte Java-Architektur sehr langsam und
haeufig auch inkonsistent.Ich habe das zwar noch nicht im Produktivbetrieb gesehen, würde das
jetzt aber eher verneinen. Meine vermutlich eher unmaßgeblichen
Erfahrungen zeigen keine größeren Probleme in dieser Richtung.Meine 128MB RAM reichen zur Entwicklung auf keinen Fall... unter
einem Gigabyte sollte man da nicht anfangen.Für die Entwicklung - zumindest von Taglibs und JSP - reicht ein
halbes Gigabyte aber auch problemlos aus. (Es geht sogar einigermaßen
mit 256 MB.) Zum eigentlichen Betrieb kann ich - wie gesagt - nicht
viel sagen.Gruß
Slyh--
Es gibt nur 10 Arten von Menschen. Solche, die das Binärsystem verstehen, und solche, die es nicht verstehen.-
Hallo Slyh,
Auf hochdeutsch heisst das: es gibt keine Programmlogik
in JSP-Seiten, nur der Code, der die Ausgabe generiert,
steht da drin. Saemtliche Programmlogik ist auf die
Servlets verteilt.Wenn man benutzerdefinierte Tags (Custom Tags -> Taglibs)
verwendet, ist überhaupt kein Java-Code mehr in der
JSP-Datei notwendig. Statt irgendwelchen Bean-Aufrufen
stehen dann nur noch spezialisierte Tags in der JSP-Datei,
die genau wie normale HTML-Tags aussehen und sich
auch so verhalten (sollten).Korrekt, danke fuer die Ergaenzung.
und wenn ich das richtig verstanden habe, sind auch
servlets nicht so das wahre?IMHO ist diese gesamte Java-Architektur sehr langsam und
haeufig auch inkonsistent.Ich habe das zwar noch nicht im Produktivbetrieb gesehen,
würde das jetzt aber eher verneinen.Oh, da kann ich Geschichten erzaehlen ;) Tatsaechlich haben
wir bei dem aktuellen Projekt (das sollte auf dieser Basis
realisiert werden) etwa doppelt so viel Geld wie sonst in
Hardware gesteckt und es ist IMHO *noch* zu langsam.Meine 128MB RAM reichen zur Entwicklung auf keinen
Fall... unter einem Gigabyte sollte man da nicht
anfangen.Für die Entwicklung - zumindest von Taglibs und JSP -
reicht ein halbes Gigabyte aber auch problemlos aus. (Es
geht sogar einigermaßen mit 256 MB.)Nicht wirklich. Beim 512MB wird immer noch sehr, sehr viel
geswapt (sehe ich immer wieder bei einem Kollegen). Von 128
will ich gar nicht erst reden...Gruesse,
CK-
Hallo CK,
Nicht wirklich. Beim 512MB wird immer noch sehr, sehr viel
geswapt (sehe ich immer wieder bei einem Kollegen). Von 128
will ich gar nicht erst reden...Also ich habe mit 512 MB keinerlei Probleme.
(Netbeans als IDE und Tomcat als Server)Was deine Kollegen verwenden, weiß ich natürlich nicht.
Grüße
Daniel
-
Hallo,
Oh, da kann ich Geschichten erzaehlen ;) Tatsaechlich haben
wir bei dem aktuellen Projekt (das sollte auf dieser Basis
realisiert werden) etwa doppelt so viel Geld wie sonst in
Hardware gesteckt und es ist IMHO *noch* zu langsam.Habt ihr da auch nichts falsch gemacht? *duck*
;-)Nicht wirklich. Beim 512MB wird immer noch sehr, sehr viel
geswapt (sehe ich immer wieder bei einem Kollegen). Von 128
will ich gar nicht erst reden...Also, mit 256 MB ist man sehr nah an Schmerzgrenze, ja. Mit 512 MB
habe aber zumindest ich absolut keine Probleme. Und das, obwohl meine
IDE (für Taglibs ist das VisualAge for Java) auch nicht gerade sehr
speicherschonend agiert. Zusätzlich läuft dann natürlich noch
Tomcat, Mozilla und eine (kleine) Datenbank. Meist sind noch ca.
150 MB frei. Also alles absolut im grünen Bereich...
Welche Software verwendet dein Kollege denn?Gruß
Slyh--
Es gibt nur 10 Arten von Menschen. Solche, die das Binärsystem verstehen, und solche, die es nicht verstehen.
-
-
-
Hallo Christian,
IMHO ist diese gesamte Java-Architektur sehr langsam und
haeufig auch inkonsistent. Meine 128MB RAM reichen zur
Entwicklung auf keinen Fall... unter einem Gigabyte sollte
man da nicht anfangen.Ich kenne jetzt von Java nur die Cleintseite, die Serverseite kann ich daher nicht beurteilen. Aber wenn man kein Swing (das ist die eigentliche Bremse) verwendet, dann ist Java schneller in der Ausführung an sich als PHP. Nur halt das Laden dauert länger. Java läuft sogar auf 133er-Pentium-I noch recht flott, wie gesagt: ohne Swing.
Ich habe in den letzten Monaten Java auf der Clientseite "kenngelernt" und finde, dass die Vorurteile, die ständig kommen, ungerechtfertigt sind. Nur das SDK könnte kleiner sein, 40 MB sind wohl doch etwas viel... (ok, ich habe DSL, aber andere nicht)
Grüße,
Christian
--
Sollen sich alle schämen, die gedankenlos sich der Wunder der Wissenschaft und Technik bedienen und nicht mehr davon erfasst haben als eine Kuh von der Botanik der Pflanzen, die sie mit Wohlbehagen frisst.
-- Albert Einstein-
Hallo,
IMHO ist diese gesamte Java-Architektur sehr langsam und
haeufig auch inkonsistent. Meine 128MB RAM reichen zur
Entwicklung auf keinen Fall... unter einem Gigabyte sollte
man da nicht anfangen.
Ich kenne jetzt von Java nur die Cleintseite, die Serverseite kann ich daher nicht beurteilen. Aber wenn man kein Swing (das ist die eigentliche Bremse) verwendet, dann ist Java schneller in der Ausführung an sich als PHP. Nur halt das Laden dauert länger. Java läuft sogar auf 133er-Pentium-I noch recht flott, wie gesagt: ohne Swing.Kann ich nur bestätigen. Das Problem mit Geschwindigkeit und Resourcenverbrauch gibt es nur in Zusammenhang mit Swing. Ok bisschen Overhead hat man auch ohne Swing dadurch das man die VM mitschleppen muss aber es hält sich in Grenzen. Vorallem nimmt das wenn die VM erstmal geladen ist nicht mehr so deutlich zu wenn mehrere Servlets hinzukommen.
Wir verwenden hier ebenfalls Tomcat auf einem Pentium-PC und haben keine Probleme. Der RAM-Verbrauch der gesamten Servlet-Engine (mit Servlets) liegt bei um die 50MB und das finde ich ganz moderat.
Und durch Just-In-Time Compiling liegt Java-Code sehr gut im Rennen.
Wenns doch mal eng wird dann unterstützt der Tomcat auch Load-Balancing.Ich habe in den letzten Monaten Java auf der Clientseite "kenngelernt" und finde, dass die Vorurteile, die ständig kommen, ungerechtfertigt sind.
Ja die Geschwindigkeit läßt schon zu wünschen übrig bei der Verwendung Swing. Die Applikation fühlt sich einfach nicht an wie eine Native, dadurch das es manchmal etwas behäbig und hakelig zugeht.
Oftmals liegt die Schuld aber am Programmierer. Swing ist eine elegante API. Aber auch recht komplex. Damit umzugehen, ist nicht so einfach.
Eine Alternative (neben AWT) wäre übrigens das SWT (als OpenSource verfügbar). Das verwendet wie AWT native Peers und zeichnet nur die Sachen selbst, die die entsprechende Plattform nicht zur Verfügung stellt. Das ist natürlich eine prima Sache. Denn das Look & Feel passt sich wirklich der jeweiligen Plattform an, so dass sich der Anwender zuhause fühlt. Selbst Themes werden berücksichtigt (siehe WinXP). Obendrein ist das ganze Resourcenschonender (RAM und CPU).
Nachteil aus Programmierersicht: Die API ist nicht ganz so elegant. Vorallem wie man C++-mäßig wieder dazu verdonnert, sich um belegte Resourcen selbst zu kümmen (das heißt es gibt Destruktoren für diese Elemente; GarbageCollection funktioniert damit nicht). Auch die Trennung von Daten und Darstellung (MVC) wie in Swing beispielsweise mit TableModel und JTable sind so in SWT nicht realisiert.
Aber immerhin. Eine Alternative.Nur das SDK könnte kleiner sein, 40 MB sind wohl doch etwas viel...
Beim SDK sehe ich nicht das Problem. Das ist eh nur für Entwickler/Administratoren. Für die reine Ausführung reicht ja das JRE. Aber selbst die ca.10MB sind eigentlich noch recht fett für Modem/ISDN-Benutzer. Ok. Bei verkauften Applikationen kann man ja das noch mit auf der CD ausliefern. Aber für Applets und Freeware wird man nicht viel Freiwillige finden, die sich das downloaden.
ups .... ist ja wieder mehr geworden als ich wollte. Vorallem nicht ganz zum Thema. Naja ok.
Gruss
MichaelB
-
-