# JSP vs PHP



## gustav-mega (3. Sep 2009)

Hallo,

wollte fragen, welche Vorteile JSP gegenüber PHP hat?


----------



## maki (3. Sep 2009)

*verschoben*

Hast du auch eine konkretere Frage?
Für so allgemeine Dinge ist Google imho besser geeignet.


----------



## Atze (3. Sep 2009)

gustav-mega hat gesagt.:


> Hallo,
> 
> wollte fragen, welche Vorteile JSP gegenüber PHP hat?



ein vorteil ist, es ist java, kein php!  java ist logischer und strikter.


----------



## tfa (3. Sep 2009)

_PHP _ist ein anderes Wort für _Nachteil_.


----------



## Atze (3. Sep 2009)

muha, tfa 4 president!!!


----------



## gustav-mega (3. Sep 2009)

ich möchte mit einem Freund demnächst eine größeres Projekt starten und wir überlegen uns, welche Programmiersprache wir dafür verwenden und wir haben lange rumgegooglet und sind zum Erschluss gekommen, dass im Bereich Sicherheit JSP besser ist und mit JSP auch mehr Möglichkeiten gibt!
Aber irgendwie habe ich das Gefühl, dass mit PHP genau so viel möglich ist, was mit JSP realisierbar ist oder täusche ich mich?
Und mit Möglichkeiten sehe ich PHP im Vorteil, z.B. GoogleMaps, da gibt es sogar Bücher in Verbindung mit PHP!


----------



## Atze (3. Sep 2009)

ja, es kommt ja auch immer drauf an, was du machen willst. für kleine, schnelle projekte im web, foren, blogs, dyn. sites ist php natürlich vorreiter. wie du schon sagtest, es gibt unzählige fertige module, und alles existiert schon irgendwo, man spart sich viel durch copy und paste. außerdem gibt es günstige webspaces / server, auf denen fast immer standardmäßig php läuft und so tolle dinge wie phpmyadmin für sql läuft. wenn du sowas brauchst, ist php sicher vorzuziehen.

sollte es aber eine große, individuelle, auf den kunden optimal angepasste sein, dann bleibt imho nur java.


----------



## ice-breaker (3. Sep 2009)

gustav-mega hat gesagt.:


> ich möchte mit einem Freund demnächst eine größeres Projekt starten und wir überlegen uns, welche Programmiersprache wir dafür verwenden


die, mit der ihr am meisten Erfahrung habt?



gustav-mega hat gesagt.:


> und wir haben lange rumgegooglet und sind zum Erschluss gekommen, dass im Bereich Sicherheit JSP besser ist


oh, das liebe ich :lol:
Du kannst in JSP genauso unsicher basteln wie in PHP, keine der Sprachen hat eine magische Wand, die dich vor unsicherem Code schützen. :lol:



gustav-mega hat gesagt.:


> Aber irgendwie habe ich das Gefühl, dass mit PHP genau so viel möglich ist, was mit JSP realisierbar ist oder täusche ich mich?


Hmm, JSP kann dank Java glaube ich ein wenig mehr, Threads könnte man zB in JSP starten, sowas gibts in PHP nur über Umwege.



gustav-mega hat gesagt.:


> Und mit Möglichkeiten sehe ich PHP im Vorteil, z.B. GoogleMaps, da gibt es sogar Bücher in Verbindung mit PHP!


du entscheidest, ob du eine Programmiersprache nutzt, weil es ein Buch dazu für Google Maps gibt :autsch:
Wenn man programmieren kann, sollte man das eigentlich nicht benötigen. Ihr solltet euch vllt besinnen, welche der beiden Sprachen ihr könnt


----------



## gustav-mega (3. Sep 2009)

erstmal Vielen Dank für die Antworten 
Gibt es aber auch eine Möglichkeit für GoogleMaps mit JSP? 
Da ich nur unter Welcome to GoogleMaps JSP Taglibrary! etwas gefunden habe, was aber nicht startet!


----------



## bygones (3. Sep 2009)

sind JSPs nicht veraltelt und JSFs zu nehmen ?!


----------



## agent47 (3. Sep 2009)

ich bin zwar noch Java Anfänger und habe mit JSP noch kein Projekt gemacht (nur ein wenig rum Probiert) aber ich entwickle mit PHP schon über 6 Jahre Webanwendungen.

Mit PHP ist schon sehr viel möglich, besonders im bezug auf Datenbanksysteme gibt es da tolle schnittstellen (z.B.: für MySQl gibt es 5 MySQL, MySQLi, beide als Klassen und normale Funktionen und seit PHP 5.3 MySQLnd).
Mit PHP kann man Bilder, XML ... verarbeiten und das auch mit einer ganz brauchbaren geschwindigkeit. JSP ist allerdings schneller und man kann Threads einsetzen was in PHP nicht geht. 

Was die Server angeht ist PHP da sehr gut unterstützt, es gibt jede menge Freehoster die Server mit PHP und MySQL und manche auch PgSQL anbieten, kostenplichtiger Webspace, VServer und Server unterstützen eigentlich zu 99,5% alle PHP. 
Bei meinem eigenen Webserver wird PHP von haus aus unterstützt aber für JSP muss ich extra für 5€ mehr im Monat ein Tomcat Modul mieten.

Vor allem kommt es auf den umfang an was du vor hast, soll es z.B.: eine Software werden die wie eine Forensoftware o.ä. an andere zum einsetzen weitergegeben werden soll ist man da mit PHP besser dabei.


----------



## gustav-mega (3. Sep 2009)

bygones hat gesagt.:


> sind JSPs nicht veraltelt und JSFs zu nehmen ?!



muss man für JSF nicht erstmal JSP lernen?



agent47 hat gesagt.:


> ich bin zwar noch Java Anfänger und habe mit JSP noch kein Projekt gemacht (nur ein wenig rum Probiert) aber ich entwickle mit PHP schon über 6 Jahre Webanwendungen.
> 
> Mit PHP ist schon sehr viel möglich, besonders im bezug auf Datenbanksysteme gibt es da tolle schnittstellen (z.B.: für MySQl gibt es 5 MySQL, MySQLi, beide als Klassen und normale Funktionen und seit PHP 5.3 MySQLnd).
> Mit PHP kann man Bilder, XML ... verarbeiten und das auch mit einer ganz brauchbaren geschwindigkeit. JSP ist allerdings schneller und man kann Threads einsetzen was in PHP nicht geht.
> ...



es soll im Bereich Gesundheitswesen eingesetzt werden und vielleicht dann später die Krankenhäuser und Apotheken einbezogen werden und wir wollen deswegen auch bevor wir mit dem Projekt anfangen uns in der ausgewählte Sprache gut einarbeiten!
zu meine obige Frage, gibt es auch eine Möglichkeit für GoogleMaps mit JSP?


----------



## maki (3. Sep 2009)

> muss man für JSF nicht erstmal JSP lernen?


Mit JSF 2.0 ist JSP tot, facelets ersetzen sie.
Darauf wollte bygones hinaus.


----------



## gustav-mega (3. Sep 2009)

maki hat gesagt.:


> Mit JSF 2.0 ist JSP tot, facelets ersetzen sie.
> Darauf wollte bygones hinaus.



könnten wir eigentlich ohne Vorkenntnisse in JSP uns an JSF ranmachen oder sollten wir erstmal uns in JSP einarbeiten und dann mit JSF anfangen?


----------



## Atze (3. Sep 2009)

wenn die zeit da ist, würde ich mir jsp mal ungucken, schaden kanns nich


----------



## maki (3. Sep 2009)

Wenn du Facelets verwendest, brauchst du kein JSP mehr.


----------



## Atze (3. Sep 2009)

ich sag ja nicht, dass er es dafür braucht, aber sollte man mal gesehen haben  ist äquivalent zu php


----------



## gustav-mega (3. Sep 2009)

könnt ihr mir vielleicht ein gutes Buch für Anfänger empfehlen?


----------



## Atze (3. Sep 2009)

zu welchem thema denn nun genau, facelets? hab ich mich noch nicht mit beschäftigt, sorry


----------



## gustav-mega (3. Sep 2009)

dürfte ich fragen was der Unterschied zwischen facelets und JSF ist?


----------



## bygones (3. Sep 2009)

gustav-mega hat gesagt.:


> dürfte ich fragen was der Unterschied zwischen facelets und JSF ist?



Facelets ? Wikipedia

gibt keinen Unterschied zw. Facelets und JSF da eins Teil des anderen ist


----------



## gustav-mega (3. Sep 2009)

nur eine Frage noch, heißt das dass JSF mächtiger ist als JSP oder sind sie gleich mächtig und JSF ist nur einen neueren Standard?


----------



## Spacerat (3. Sep 2009)

Mal ein ganz feiner, oft nicht gesehener Vorteil von JSP/JSF und oder DotNet-ASP gegenüber PHP. PHP wird per Aufruf immer neu geparsed und kompiliert. Dieser Vorgang geschieht bei den anderen Web-Anwendungen einmalig vor bzw. während der Veröffentlichung. Dadurch wird ein Angriff, genannt "Code-Injection", verhindert. Ein Nachteil von JSP/JSF dürfte sein, dass man nach Anbietern von Webspace, die JSP/JSF anbieten, akribisch suchen muss. Da muss man im Zweifelsfall schon auf Miet-Server ausweichen.


----------



## gustav-mega (3. Sep 2009)

Spacerat hat gesagt.:


> Mal ein ganz feiner, oft nicht gesehener Vorteil von JSP/JSF und oder DotNet-ASP gegenüber PHP. PHP wird per Aufruf immer neu geparsed und kompiliert. Dieser Vorgang geschieht bei den anderen Web-Anwendungen einmalig vor bzw. während der Veröffentlichung. Dadurch wird ein Angriff, genannt "Code-Injection", verhindert. Ein Nachteil von JSP/JSF dürfte sein, dass man nach Anbietern von Webspace, die JSP/JSF anbieten, akribisch suchen muss. Da muss man im Zweifelsfall schon auf Miet-Server ausweichen.



dann so wie ich es verstehe, JSF ist nur für eine bessere Übersichtlichkeit und JSP und HTML ist genau so mächtig wie JSF und JSP oder Facelets, richtig?


----------



## Spacerat (3. Sep 2009)

Kommt drauf an, was man als "mächtig" betrachtet. Ich habe JSF bisher schlicht als eine Art Tag-Lib ala JSP (ist natürlich nicht so ) und deswegen auch als gleichermassen mächtig gesehen. Allerdings habe ich mich mit JSF noch gar nicht so eindringlich wie mit JSP befasst.


----------



## Atze (3. Sep 2009)

ich habe bisher auch nur jsp (und dabei mehr scriptlet als taglib) eingesetzt, aber irgendwas wird JSF JSP schon vorraus haben, sonst wäre es nicht der "tolle, neue standard", oder?  vielleicht kann uns da jemand mehr sagen


----------



## Prismapanda (4. Sep 2009)

JSF ist ein Framework, welches auf der jsp Technologie aufbaut. Es ist deshalb von der Technologie nicht "mächtiger" als jsps, aber man kann halt (vorrausgesetzt man beherrscht es) ziemlich schnell und einfach eine Webanwendung zaubern. Und Facelets ist eine View Technik. Die Taglibs werden dabei nicht mehr über jsp Tags definiert, sondern innerhalb eines wohlgeformten xml Dokuments. Insofern schreibst du mit Facelets .xml Dokumente anstatt .jsps, was aber nicht heißt, dass man deshalb nichts über jsp zu wissen braucht. Schließlich ist es wie gesagt nur ein Framework, nutzt also die jsp Technologie. (Die Anfragen gehen übrigens an ein Front Controller *Servlet*)
Wenn man keine Ahnung von jsp hat, ist die Einarbeitungszeit in jsf ziemlich lange, bzw. man programmiert am Anfang ein wenig ins Blaue.
Es sei hier aber auch gesagt, dass jsf halt als Framework diverse Arbeiten abstrahiert, sodass man insbesondere spezielle Vorgänge nur durch genaue Kenntnis von den internen Abläufen oder diverser Tricks o.ä. hinbekommt.

Wenns schnell gehen soll spricht doch nichts gegen php, der höhere Anspruch und "Mächtigkeit" liegt aber definitiv bei jsp/jsf.

btw.: es gibt auch für php Frameworks ;-)


----------



## gustav-mega (4. Sep 2009)

ich glaube, werde erstmal mit JSP anfangen und dann mich mit JSF und Facelets beschäftigen


----------



## Spacerat (4. Sep 2009)

Prismapanda hat gesagt.:


> Die Anfragen gehen übrigens an ein Front Controller *Servlet*


Also eines ist schon mal Sicher: Auch bei JSP gehen die Anfragen über ein *Servlet*. Zumal die JSPs von z.B. Jasper bei Tomcat in ein solches kompiliert werden. Weis blos nicht ob das zum Zeitpunkt der Veröffentlichung oder beim Erstauruf des JSPs geschieht.


----------



## Noctarius (4. Sep 2009)

Man kann beides machen. Mit JSPC kann man JSP Dateien "Vorkompilieren" und damit werden sie (z.B. vom Maven JSP Plugin) auch direkt als Servlet in der web.xml verewigt. Sind diese nicht vorkompiliert kommt bei der Tomcat-Standardeinstellung (diese ist abschaltbar) ein Vergleichsroutine beim Aufruf des JSPs zum Zuge. Diese kompiliert das JSP in ein Servlet (beim ersten Aufruf) und speichert den "Last-Changed" Wert des JSP. Sollte sich das Datum vom "Last-Changed" nun während der Laufzeit ändern wird erneut umgewandelt in ein Servlet.

Mit abgeschalteter Reload-Automatik wird beim ersten Aufruf das JSP umgewandelt, kompilert und geladen und bleibt dann auch bei Änderungen zur Laufzeit konsistent auf dem ersten Stand. Erneut startet der Umwandlungsprozess dann erst nach einem Serverneustart.


----------



## bronks (6. Sep 2009)

agent47 hat gesagt.:


> ... JSP ist allerdings schneller und man kann Threads einsetzen was in PHP nicht geht ...


Das ist einer der wenigen positiven Punkte an JSP, denn sonst wurde in den letzen Jahren m.E. an Java zu viel kaputtgebastelt und verschlimmbessert.

Weiterer sehr grosser Vorteil von PHP: Es läuft problemlos auch auf dem IIS und stellt sich v.a. bei NTLM und anderen sinnvollen Sachen von MS nicht quer.


----------



## gustav-mega (6. Sep 2009)

bronks hat gesagt.:


> Das ist einer der wenigen positiven Punkte an JSP, denn sonst wurde in den letzen Jahren m.E. an Java zu viel kaputtgebastelt und verschlimmbessert.
> 
> Weiterer sehr grosser Vorteil von PHP: Es läuft problemlos auch auf dem IIS und stellt sich v.a. bei NTLM und anderen sinnvollen Sachen von MS nicht quer.



aber JSP ist doch eher zu empfehlen als PHP, oder?


----------



## tfa (6. Sep 2009)

gustav-mega hat gesagt.:


> aber JSP ist doch eher zu empfehlen als PHP, oder?



Ja, absolut! Praktisch alles andere ist eher zu empfehlen als PHP. Wenn es nicht JSP, JSF o.ä. sein soll, nimm Grails oder Rails. Das sind im Gegensatz zu PHP durchdachte Frameworks, die Spaß machen. 



> Weiterer sehr grosser Vorteil von PHP: Es läuft problemlos auch auf dem IIS


Von allen vermeindlichen Argumenten für PHP ist das wohl eins der dümmeren.


----------



## bronks (6. Sep 2009)

gustav-mega hat gesagt.:


> aber JSP ist doch eher zu empfehlen als PHP, oder?


Für WebApps ist PHP einfach und unkompliziert. Bei JSP hat man das Problem, daß diese auf Servlets und Java basieren und nur eine Erweiterung für diese beiden Techniken darstellt. Deshalb kommt man irgendwan nicht umherum sich mit Servlets und Java zu beschäftigen. Sobald man in Java einen neue Technik anfaßt ist man gezwungen einen riesigen Schwanz an abhängigen Techniken mit sich zu ziehen, für welche man sich nicht im Ansatz interessiert. Das alles erfordert übermäßige Einarbeitungszeit. Zudem sind alle neuen Techniken auf irgendetwas altem aufgebaut, was zwangsweise dazu führt, daß man zwar neue Vorteile hat, aber irgenwo immer auf alte Probleme stößt.

Für Insider: J2EE war als Spec die absolute Blamage. Freihändig war es nicht zu Coden. Es wurde von den Entwicklern akzeptiert, warum auch immer. Schlaue Leute haben dafür Codegeneratoren in IDEs geschaffen und die Krönung war wohl XDoclet, dem es zu verdanken war, daß J2EE einfach und unkopliziert wurde. Dann kommt man mit der Spec für EE5, was nur eine halbe Sache ist, die aus Not und Panic rausgeworfen wurde und eigentlich nur ein Rückschritt in Richtung EDV zu Fuß darstellt.

Über die letzen Entwicklungen bin ich mehr als angefressen. Es ist nur noch ein Krieg der Spezifikationen, welche das leben leichter machen sollen, aber es nicht tun.

Vor 8 Jahren war es für mich eine politische Entscheidung Java zu wählen. Nach dem das ganze jetzt Verorakelt ist, stellt sich die Frage nicht mehr, zu dem bin ich mitten drin und lang mir öfter ans Hirn.


----------



## gustav-mega (6. Sep 2009)

bronks hat gesagt.:


> Für WebApps ist PHP einfach und unkompliziert. Bei JSP hat man das Problem, daß diese auf Servlets und Java basieren und nur eine Erweiterung für diese beiden Techniken darstellt. Deshalb kommt man irgendwan nicht umherum sich mit Servlets und Java zu beschäftigen. Sobald man in Java einen neue Technik anfaßt ist man gezwungen einen riesigen Schwanz an abhängigen Techniken mit sich zu ziehen, für welche man sich nicht im Ansatz interessiert. Das alles erfordert übermäßige Einarbeitungszeit. Zudem sind alle neuen Techniken auf irgendetwas altem aufgebaut, was zwangsweise dazu führt, daß man zwar neue Vorteile hat, aber irgenwo immer auf alte Probleme stößt.
> 
> Für Insider: J2EE war als Spec die absolute Blamage. Freihändig war es nicht zu Coden. Es wurde von den Entwicklern akzeptiert, warum auch immer. Schlaue Leute haben dafür Codegeneratoren in IDEs geschaffen und die Krönung war wohl XDoclet, dem es zu verdanken war, daß J2EE einfach und unkopliziert wurde. Dann kommt man mit der Spec für EE5, was nur eine halbe Sache ist, die aus Not und Panic rausgeworfen wurde und eigentlich nur ein Rückschritt in Richtung EDV zu Fuß darstellt.
> 
> ...



es geht um ein etwas größeren Projekt, was über eine längere Zeit dauern würde und deswegen Einarbeiten ist ein Muss!
Aber außer dass PHP leichter zu lernen ist, und das Programmieren damit schneller geht, höre ich ehrlich gesagt keine andere Begründung, oder sehe ich es falsch?


----------



## bronks (6. Sep 2009)

tfa hat gesagt.:


> ... Wenn es nicht JSP, JSF o.ä. sein soll, nimm Grails oder Rails. Das sind im Gegensatz zu PHP durchdachte Frameworks, die Spaß machen.


Genau diese Framworks sind das größte Übel. Schleppen diverse eigene Libs und dann noch einen haufen von fremdanbietern mit, um mir eine bestimmte Arbeitsweise aufzuzwingen und zu dem noch konkurrierende Specs zu SUN  mitbringen. Da bin ich m.E. schon extrem tolerant, weil ich einen Compiler mit ausgewählten und erprobten (legacy) Libs, eine VM und das Betriebssystem als zusätzliche Fehlerquellen zwischen meinem Code und der Hardware akzeptiere. 



tfa hat gesagt.:


> Von allen vermeindlichen Argumenten für PHP ist das wohl eins der dümmeren.


Was denn? PHP bringt es mit der Standardinstallation auf dem IIS mit. Um etwas vergleichbares mit Java zu erreichen braucht man IIS, Connector und Tomcat, was am sichersten ist oder Spring soll damit angeblich auch zurechtkommen, in was man sich noch extra einarbeiten darf.


----------



## tfa (6. Sep 2009)

bronks hat gesagt.:


> Für WebApps ist PHP einfach und unkompliziert. Bei JSP hat man das Problem, daß diese auf Servlets und Java basieren und nur eine Erweiterung für diese beiden Techniken darstellt. Deshalb kommt man irgendwan nicht umherum sich mit Servlets und Java zu beschäftigen.



Was soll denn das für ein Argument sein? Wenn man JSP einsetzt, muss man sich irgendwann mit Java beschäftigen? (Hoffentlich schon davor). Wofür glaubst du, steht das J in JSP? Ebensogut kann ich sagen, man muss sich mit PHP befassen, um PHP zu benutzen. Hier heißen Sprache und Framework eben nur gleich.



> Sobald man in Java einen neue Technik anfaßt ist man gezwungen einen riesigen Schwanz an abhängigen Techniken mit sich zu ziehen, für welche man sich nicht im Ansatz interessiert. Das alles erfordert übermäßige Einarbeitungszeit. Zudem sind alle neuen Techniken auf irgendetwas altem aufgebaut, was zwangsweise dazu führt, daß man zwar neue Vorteile hat, aber irgenwo immer auf alte Probleme stößt.


Ich nehme an, mit "abhängigen Techniken" meinst du sowas wie Frameworks oder Bibliotheken. Das finde ich gerade ein Vorteil von Java, dass es ein Auswahl ein Libs gibt, die meistens auch frei einsetzbar, robust, gut getestet und einfach nur praktisch sind. Die Alternative wäre, immer alles selbst zu basteln. Das mag in der PHP-Welt Stand der Dinge sein. Wenn du professionell arbeitest, wird dich keiner dafür bezahlen, das (möglicherweise eckige) Rad immer wieder neu zu erfinden.
Wenn man Software entwickelt, sollte man sich schon _im Ansatz dafür interessieren_, was man tut.



> Genau diese Framworks sind das größte Übel. Schleppen diverse eigene Libs und dann noch einen haufen von fremdanbietern mit, um mir eine bestimmte Arbeitsweise aufzuzwingen und zu dem noch konkurrierende Specs zu SUN mitbringen.


Das kann ich jetzt überhaupt nicht verstehen. Du empfiehlst PHP, aber Rails ist das größte Übel? Wo ist das Problem mit den diversen Libs? Du willst wirklich alles selbst zusammenfrickeln? Wird dir durch PHP keine Arbeitsweise "aufgezwungen"? Sollte die besser sein, als von irgendeinem anderen, modernerem Web-Framework?


----------



## bronks (6. Sep 2009)

tfa hat gesagt.:


> Was soll denn das für ein Argument sein?


Das ist das Argument dafür warum EE5 halbfertig auf das Publikum losgelassen wurde. In zu vielen bedeutenden Projekten hat man sich nicht für Java entschieden, weil zu umständlich.



tfa hat gesagt.:


> Wenn man JSP einsetzt, muss man sich irgendwann mit Java beschäftigen? (Hoffentlich schon davor). Wofür glaubst du, steht das J in JSP?  Ebensogut kann ich sagen, man muss sich mit PHP befassen, um PHP zu benutzen. Hier heißen Sprache und Framework eben nur gleich.


Ja, aber in JSP gibt es Tag, die das gleiche bewirken wie JavaCode, der von der Schreibweise anders, aber nicht länger oder sogar besser ist. Um absolut das gleiche zu erreichen soll ich lt. irgenwelchen Conventions in JSP den JspTag, anstatt JavaCode verwenden. Damit muß ich für absolut die gleiche Sache doppelt soviel wissen.




tfa hat gesagt.:


> Ich nehme an, mit "abhängigen Techniken" meinst du sowas wie Frameworks oder Bibliotheken. Das finde ich gerade ein Vorteil von Java, dass es ein Auswahl ein Libs gibt, die meistens auch frei einsetzbar, robust, gut getestet und einfach nur praktisch sind.


Schön wenn es so wäre. Nicht nur aus Gaudi arbeite ich in Projekten, welche noch auf Java1.3 laufen. Legacy, aber es funktioniert zuverlässig.



tfa hat gesagt.:


> Die Alternative wäre, immer alles selbst zu basteln. Das mag in der PHP-Welt Stand der Dinge sein.


Ist es nicht, denn für alle sinnvollen Sachen gibt es in PHP eine Funktion, welche in der Standardinstallation dabei ist. So z.b. MD5, wo ich für eine verschlüsselung mit Java einen 20zeiligen Code brauche evtl. gibt es ja schon eine ext Lib, die das beinhaltet.




tfa hat gesagt.:


> Wenn du professionell arbeitest, wird dich keiner dafür bezahlen, das (möglicherweise eckige) Rad immer wieder neu zu erfinden.


In PHP nimmt man immer das eine einzige vorgefertigte Rad, welches bei angemessener Fahrweise immer zuverlässig läuft



tfa hat gesagt.:


> Wenn man Software entwickelt, sollte man sich schon _im Ansatz dafür interessieren_, was man tut.


Ja genau und das wird immer Mißverstanden. Ich bin Softwareentwickler und in einem auch noch der Progger. Ich bestelle ein Rad lege die gewünschten Eigenschaften fest und möchte es geliefert bekommen. Mich interessiert nicht im geringsten, wie sich die Gummimischung zusammensetzt oder aus welchem Material das Radlager besteht. Es soll gefälligst funktionieren, ohne daß ich daran nachbessern muß.




tfa hat gesagt.:


> Das kann ich jetzt überhaupt nicht verstehen. Du empfiehlst PHP, aber Rails ist das größte Übel?


Rails existiert zwar, aber es fehlt die Anerkennung.



tfa hat gesagt.:


> Wo ist das Problem mit den diversen Libs? Du willst wirklich alles selbst zusammenfrickeln?


z.B. Webservice. Zig Libs, die zwar WS unterstützen, aber es fehlt ein wegweisender Standard. Es ist schön, daß es in EE5 etwas entkompliziert wurde, aber verwenden will den offiziellen Standard fast niemand. Weil u.a. bedeutende Features fehlen.



tfa hat gesagt.:


> Wird dir durch PHP keine Arbeitsweise "aufgezwungen"? Sollte die besser sein, als von irgendeinem anderen, modernerem Web-Framework?


Definitiv nicht und wenn es für mich OK ist, dann funktioniert auch Spaghetticode. Blicke in Richtung PHP und ASP, dann sehe ich immer und überall, falls ordentlich gecodet, MVC mit Controller im HTML-Teil ingegriert. In Java nennt man das offizielle JspFrontStrategy. Das ist eine saubere und unkomplizierte Sache. In Java hat das Pattern in Wirklichkeit nur aus dem Grund niemand verwendet, weil es viel zu lange keine Möglichkeit gab den JavaCode, der JSP, ordentlich zu debuggen. Deshalb hat sich ServletFrontStrategy durchgesetzt, worauf auch Struts mit dem Ziel aufbaut, ein wenig für Ordnung zu sorgen, was man mit einer aufgeblasenen Configdatei später bezahlt. Ob Struts-Config oder Web-Config, es stehen Sachen drin, die eigentlich unnütz sind und aus einer Schwäche bzw. Unfähigkeit des Debuggers resultieren. Genau auf sowas bauen dann weitere JavaTechniken auf.


----------



## ice-breaker (7. Sep 2009)

gustav-mega hat gesagt.:


> es geht um ein etwas größeren Projekt, was über eine längere Zeit dauern würde und deswegen Einarbeiten ist ein Muss!
> Aber außer dass PHP leichter zu lernen ist, und das Programmieren damit schneller geht, höre ich ehrlich gesagt keine andere Begründung, oder sehe ich es falsch?


du bist in einem Java-Forum 
Ich baue WebApps aber auch lieber in PHP, die Begründung?
Geschmackssache und die Typlosigkeit macht es oft doch auch einfacher, aber manchmal wünscht man sie sich dann doch, aber ohne Framework in PHP etwas zu bauen, wäre wirklich nur Frickelei.
Zend Framework, Code Igniter, CakePHP, Symfony, Prado...
Also irgendeines sollte es schon sein, sonst endet es meist in Spaghetti-Code mit 5000 Include-Statements, leider schon zu oft gesehen :noe:




bronks hat gesagt.:


> Ist es nicht, denn für alle sinnvollen Sachen gibt es in PHP eine Funktion, welche in der Standardinstallation dabei ist. So z.b. MD5, wo ich für eine verschlüsselung mit Java einen 20zeiligen Code brauche evtl. gibt es ja schon eine ext Lib, die das beinhaltet.


ALLES ist in php auch nicht drinne, also der Funktionsumfang von Java ist da deutlich höher, es ist nur nicht immer so ein Single-Statement wie in PHP.




bronks hat gesagt.:


> Definitiv nicht und wenn es für mich OK ist, dann funktioniert auch Spaghetticode. Blicke in Richtung PHP und ASP, dann sehe ich immer und überall, falls ordentlich gecodet, MVC mit Controller im HTML-Teil ingegriert.


Glückwunsch, aber das meiste ist leider Frickelhaft implementiert, gerade die größeren Dienste, wenn ich daran denke wie Facebook aussieht - Spaghetticode^10 _(Facebook hat vor knapp einem Jahr oder so, für ne halbe Stunde plain-php-code gesendet statt es ausgeführt)_


----------



## marasek (3. Okt 2009)

ice-breaker hat gesagt.:


> du bist in einem Java-Forum
> Ich baue WebApps aber auch lieber in PHP, die Begründung?
> Geschmackssache und die Typlosigkeit macht es oft doch auch einfacher, aber manchmal wünscht man sie sich dann doch, aber ohne Framework in PHP etwas zu bauen, wäre wirklich nur Frickelei.
> Zend Framework, Code Igniter, CakePHP, Symfony, Prado...
> Also irgendeines sollte es schon sein, sonst endet es meist in Spaghetti-Code mit 5000 Include-Statements, leider schon zu oft gesehen :noe:



Man kann sich auch ein eigenes Framework schreiben...ich habe keine Lust, mehr Zeit mit der Einarbeitung und dem Ringen mit einem Fremdsystem zu verbringen als mit produktivem Code schreiben.



> ALLES ist in php auch nicht drinne, also der Funktionsumfang von Java ist da deutlich höher, es ist nur nicht immer so ein Single-Statement wie in PHP.



Sagen wir so, ich finde PHP out of the box für Webapplikationen angenehmer. Installieren, losfrickeln, kein Rattenschwanz.

Java finde ich auf Grund der IDE-Integration angenehmer, aber egal was man bei Java macht, es hängt irgendwie _immer_ ein Rattenschwanz dran. Bzw. eine ganze Ratte, die gerade von einer Python verschlungen wird, an der ein Mungo hängt, der schon halb im Maul einer Raubkatze ist.


----------



## MrWhite (4. Okt 2009)

gustav-mega hat gesagt.:


> dürfte ich fragen was der Unterschied zwischen facelets und JSF ist?



Facelets ist eine Library fuer JSF, mit dem du das Layout deines UIs besser steuern kannst.

"A poor man's templating engine", wuerde ich sagen.

Warum hier ueber PHP hergezogen wird, kann ich nicht nachvollziehen. Ich habe jetzt recht lange mit JSF gearbeitet und muss sagen, dass ich JSF fuer einen rechten Mist halte.

1.) Es ist unglaublich aufwaendig, eigene Components zu schreiben. Wer immer sich dieses System ausgedacht hat, gehoert dafuer, ahem, geruegt.

2.) Wenn du Dinge tun willst, die der Standard nicht abdeckt oder sonst irgendwas tun willst, was irgendwie abweicht, hast du mit JSF echten Aufwand um Workarounds zu schaffen, die auch noch versionsunabhaengig funktionieren (ich rede hier von minor-versions). Durch zusaetliche Dinge wie richfaces wird die Sache nicht besser gemacht. Scheinbar einfache Dinge zu tun, wie z.B. Tooltips auf Tabellenheader zu legen werden so zu einem riesigen Akt.


Das naechste Webprojekt werde ich vermutlich nicht mit JSF realisieren. EJB3 Container im Hintergrund und JPA sind mehr oder weniger geritzt, aber das Frontend were ich wohl mit etwas anderem bauen. Vielleicht php und jQuery. Das integriert vielleicht nicht so nahtlos, ist aber einfacher, engt mich nicht ein und die Entwicklung duerfte wesentlich flotter von der Hand gehen.


----------



## marasek (5. Okt 2009)

MrWhite hat gesagt.:


> Facelets ist eine Library fuer JSF, mit dem du das Layout deines UIs besser steuern kannst.
> 
> "A poor man's templating engine", wuerde ich sagen.
> 
> Warum hier ueber PHP hergezogen wird, kann ich nicht nachvollziehen. Ich habe jetzt recht lange mit JSF gearbeitet und muss sagen, dass ich JSF fuer einen rechten Mist halte.



Ich denke, es kann nicht heissen "PHP gegen JSF", weil ja JSF schon einen Schritt weitergeht als reines <?php ?>.



> 1.) Es ist unglaublich aufwaendig, eigene Components zu schreiben. Wer immer sich dieses System ausgedacht hat, gehoert dafuer, ahem, geruegt.



YMMD.



> 2.) Wenn du Dinge tun willst, die der Standard nicht abdeckt oder sonst irgendwas tun willst, was irgendwie abweicht, hast du mit JSF echten Aufwand um Workarounds zu schaffen, die auch noch versionsunabhaengig funktionieren (ich rede hier von minor-versions). Durch zusaetliche Dinge wie richfaces wird die Sache nicht besser gemacht. Scheinbar einfache Dinge zu tun, wie z.B. Tooltips auf Tabellenheader zu legen werden so zu einem riesigen Akt.



Meiner Ansicht nach ein typisches Framework-Problem. 80% des Projekts in 20% der Zeit, die restlichen 20% benötigen die restlichen 80%...denn irgendwas ist eigentlich immer.
Und wenn man sich die Workarounds gebastelt hat, hockt man beim nächsten Upgrade mit gekreuzten Fingern da.



> Das naechste Webprojekt werde ich vermutlich nicht mit JSF realisieren. EJB3 Container im Hintergrund und JPA sind mehr oder weniger geritzt, aber das Frontend were ich wohl mit etwas anderem bauen. Vielleicht php und jQuery. Das integriert vielleicht nicht so nahtlos, ist aber einfacher, engt mich nicht ein und die Entwicklung duerfte wesentlich flotter von der Hand gehen.



Mal ne andere Frage - gibt es die Möglichkeit, mit Java ähnlich simpel, d. h. fast ohne Rattenschwanz, Webapplikationen zu programmieren? CGI fiele mir ein, oder ein simpler Webserver in Java, der den Applikationscode enthält, gibt es noch einen Ansatz? Quasi wirklich nur

<html>
<body>
<?
//here be java code
?>
</body>
</html>


----------



## homer65 (5. Okt 2009)

Ich habe schon einiges mit JSP entwickelt. Mittlerweile halte ich es - vorausgesetzt man kommt gut mit Java zurecht - für sehr einfach und unkompliziert. Diese ganzen Frameworks erfordern viel Einarbeitung, was mich bisher abgeschreckt hatt. Außerdem hatt man mit einem Framework weniger Möglichkeiten. Dafür werden einem gewisse, aber eben nicht alle, Dinge vereinfacht.


----------



## maki (5. Okt 2009)

> Mal ne andere Frage - gibt es die Möglichkeit, mit Java ähnlich simpel, d. h. fast ohne Rattenschwanz, Webapplikationen zu programmieren? CGI fiele mir ein, oder ein simpler Webserver in Java, der den Applikationscode enthält, gibt es noch einen Ansatz? Quasi wirklich nur
> 
> <html>
> <body>
> ...


Klar, nennt sich Skriptlets und davon wird dringend abgeraten, weil "dreckig" und so gar nicht MVC


----------



## tfa (5. Okt 2009)

maki hat gesagt.:


> Klar, nennt sich Skriptlets und davon wird dringend abgeraten, weil "dreckig" und so gar nicht MVC



Wer sowas braucht, kann auch ruhig bei PHP bleiben...


----------



## bronks (5. Okt 2009)

@maki + tfa:
Wie nennt sich das:


```
<%
//here be java code
%>
<html>
<body>
... ... ...
</body>
</html>
```


----------



## tfa (5. Okt 2009)

bronks hat gesagt.:


> @maki + tfa:
> Wie nennt sich das:


Trollversuch eines _Experten_?


----------



## maki (5. Okt 2009)

Auch ein Skriptlet.


----------



## MrWhite (5. Okt 2009)

Besonders schlimm finde ich es übrigens, wenn clientseitiges JS zusammen mit JSF genutzt werden muss. Das macht einfach keinen Spass. Da ist man mit reinem HTML und somit voller Kontrolle schneller, als wenn man für JSF Workarounds bastelt. Zudem ist es wesentlich sauberer. Das behaupte ich zumindest mal.


----------



## bronks (5. Okt 2009)

@tfa + maki:
Eigentlich wollte ich hören, daß es eine perfekte Schablone ist, den MVC Controller in JSP Front Strategy zu auszuprogrammieren, wie in den Patternkatalogen zu J2EE u.a. vorgeschlagen.

Das ist eine "saubere" Technik, die einem das Servlet und das herumgefrickel in der web.xml erspart. Diese hat sich eigentlich nur in Java nicht durchgesetzt, weil Debugger und IDEs damit zu der entscheidenden Zeit noch nicht zurechtgekommen sind.

Mit der Zeit habe ich mehrere solche unsinnige Krücken in Java kennengelernt, an denen aus unerklärbaren gründen festgehalten wird.


----------



## maki (5. Okt 2009)

> Eigentlich wollte ich hören, daß es eine perfekte Schablone ist, den MVC Controller in JSP Front Strategy zu auszuprogrammieren, wie in den Patternkatalogen zu J2EE u.a. vorgeschlagen.


Ähh.. das wirst du von mir nicht hören, weil es halt nicht stimmt.
Den Controller in die View zu programmieren ist das Gegenteil von SOC und das Gegenteil  MVC.
Wie du darauf kommst dass das im JEE Pattern Katalog vorgeschlagen wird, würde ich trotzdem gerne wissen, genau das wird mit dem JEE Patternkatalog verhindert bzw. nicht empfohlen(vom sog. "Model 1" wurde immer schon abgeraten ).



> Das ist eine "saubere" Technik, die einem das Servlet und das herumgefrickel in der web.xml erspart. Diese hat sich eigentlich nur in Java nicht durchgesetzt, weil Debugger und IDEs damit zu der entscheidenden Zeit noch nicht zurechtgekommen sind.


Nein, ist nicht sauber und hat auch nix mit Debuggingunterstützung zu tun.
MVC war das Ziel, sauber baer eben aufwändiger.


----------



## bronks (5. Okt 2009)

maki hat gesagt.:


> ... MVC. Wie du darauf kommst dass das im JEE Pattern Katalog vorgeschlagen wird, würde ich trotzdem gerne wissen, genau das wird mit dem JEE Patternkatalog verhindert bzw. nicht empfohlen(vom sog. "Model 1" wurde immer schon abgeraten ).


Doch, doch. Das ist absolut konform zu MVC Model 2 und steht in den Sun Blue Prints immer noch so drin, denn es ist egal, ob absolut der selbe ControllerCode im Servlet oder oder im Kopf der JSP steht, denn die Anfrage geht so oder so direkt an den Controller.



maki hat gesagt.:


> Nein, ist nicht sauber und hat auch nix mit Debuggingunterstützung zu tun ... ...


Doch klar. Notgedrungen hat man den Controller im Servlet belassen, da kaum ein Debuggingwerkzeug sich für die Breakpoints in der JSP interessiert hat und wenn, dann hat das Programm an total blödsinnigen Stellen angehalten.  War insgesammt ein toller Workaround, um die Sitiuation zu retten, aber eigentlich hätte man alles lieber in der JSP gehabt und Servlets nur für LowLevelSachen propagiert.


----------



## marasek (5. Okt 2009)

Bevor das zum üblichen "I am smarter than thou" degeneriert, eine Erläuterung: wenn ich mit PHP programmiere, habe ich eine index.php5. Darin wird der Klassenlader definiert, Konfiguration geladen & sonstiger Krimskrams, und danach gibt es den Aufruf des Frontcontrollers. Irgendwo gammeln dann noch ein paar HTML-Templates rum. 

Übrigens ist MVC nicht der Weisheit letzter Schluss. Mal angenommen, man gibt eine grosse Tabelle aus. echo "<td>".$cell."</td>"; ist nicht sonderlich elegant, hat aber den Vorteil, dass die Liste bereits angezeigt wird, während die Liste geladen wird.

By the book ist das anders - da kommt eine längere Zeit die Sanduhr und dann die Seite, bis die Daten von der Datenbank ins Model, vom Model in das TableWidget, vom Widget ins Template und vom Template an den Browser gegangen sind...


----------



## Spin (5. Okt 2009)

Einfach mal WIKI schauen 

JSP ist einfach zu erlernen , wenn du die Basics von Java beherschst. Es sollte für einen PHP entwickler der schon 6 Jahre dabei ist kein Problem sein.

Naja ich kenn einige die haben noch nie was von OOP gehört.......also nur prozedural programmiert.

Das kann dann doch zu schwierigkeiten kommen. Aber versucht euch 

Tipp: Galileo open sourcs OOP

schau euch das an, grüße


----------



## maki (5. Okt 2009)

> Doch, doch. Das ist absolut konform zu MVC Model 2 und steht in den Sun Blue Prints immer noch so drin, denn es ist egal, ob absolut der selbe ControllerCode im Servlet oder oder im Kopf der JSP steht, denn die Anfrage geht so oder so direkt an den Controller.


Natürlich macht es einen Riesenunterschied ob ich den Java Code in die JSP Schreibe oder einen extra Servlet als Controller  verwende.
Aber du hast sicherlich einen Link zu den Blueprints der deine Behauptung belegt, nicht wahr? 



> Doch klar. Notgedrungen hat man den Controller im Servlet belassen, da kaum ein Debuggingwerkzeug sich für die Breakpoints in der JSP interessiert hat und wenn, dann hat das Programm an total blödsinnigen Stellen angehalten. War insgesammt ein toller Workaround, um die Sitiuation zu retten, aber eigentlich hätte man alles lieber in der JSP gehabt und Servlets nur für LowLevelSachen propagiert.


Ich denke du solltest dir wirklich mal die Grundlagen der Webentwicklung in Java ansehen...


----------



## bronks (5. Okt 2009)

maki hat gesagt.:


> ... Aber du hast sicherlich einen Link zu den Blueprints der deine Behauptung belegt, nicht wahr?  ...


Klar doch: Core J2EE Patterns - Front Controller

Der Absatz über Beispielcode 7.15 beschreibt das was ich oben geschrieben habe. Testing und Debugging von JavaCode in JSP war ein fast unmöglicher Grusel zu der Zeit wo das Dokument geschrieben wurde.


----------



## maki (5. Okt 2009)

Das hier


> Ich denke du solltest dir wirklich mal die Grundlagen der Webentwicklung in Java ansehen...


nehme ich zurück.



> Der Absatz über Beispielcode 7.15 beschreibt das was ich oben geschrieben habe. Testing und Debugging von JavaCode in JSP war ein fast unmöglicher Grusel zu der Zeit wo das Dokument geschrieben wurde.


Da wird auch klar davon abgeraten (bzw. der Vorzug wird dem Controller Servlet gegeben) den Controller in die JSP mitreinzuprogrammieren, aber nicht wegen dem Debugging:


> JSP Front Strategy
> 
> This strategy suggests implementing the controller as a JSP page. Though semantically equivalent, the Servlet Front Strategy is preferred to the JSP Front Strategy. Since the controller handles processing that is not specifically related to display formatting, it is a mismatch to implement this component as a JSP page.
> 
> Implementing the controller as a JSP page is clearly not preferred for another reason: It requires a software developer to work with a page of markup in order to modify request handling logic. Thus, a software developer will typically find the JSP Front Strategy more cumbersome when completing the cycle of coding, compilation, testing, and debugging. Example 7.15 is an example of the JSP Front Strategy.


Jedenfalls ist da nicht von der "perfekten Schablone" die Rede


----------

