Andreas: Kompatibilität von PHP4/5 und PHP vs. JSP

Moin!

Habe gerade einen recht interessanten Artikel zu PHP5 gelesen:

http://www-user.tu-chemnitz.de/~meal/php/php5/

Darin steht unter anderem, dass mit der Kompatibilität zwischen PHP 4 und 5 bewußt gebrochen wird, halt mit den globalen Varblen, das $HTTP_*_VARS wohl nicht mehr unterstützt werden(!!!)... Das ist aber ziemlich dumm! Wird aber wohl noch etwas dauern bis es von PHP 5 in einer stabilen Version gibt. Muß ich dann irgendwann mal "register_globals" auf "off" stellen und dann direkt alles gegen $_get... ersetzen? Wie soll das bei "laufenden" Seiten reibungslos funktionieren?
Da ich erst ein gutes halbes Jahr mit PHP zu tun habe, habe ich die von der Umstellung von 3 auf 4 nichts mitbekommen, aber da gab es ja was mit Endungen(.php3). Wie hat das da funktioniert? Konnte man da auf einem Server parallel Seiten mit PHP3 und 4 laufen haben?

Aber alles in allem hören sich die Neuerungen alle ganz gut an, auch bzgl OOP. Da will man wohl auch mit JSP konkurrieren können.
Kennt sich jemand von Euch mit JSP aus? Wo liegen da die Vor- und Nachteile zu PHP? Was gibt es bei JSP für Serverseitige Voraussetzungen? Warum haben fast alle "mietbaren" Server PHP, oder wenigstens ASP, aber so gut wie keine JSP(mir sind jedenfalls keine bekannt!)? Ich hatte nämlich mal gehört, das JSP wirklich gut sein soll!? Außerdem sind eine Menge wirklich guter, großer und teurer Seiten in JSP programmiert!

Aber PHP 5, Apache 2 und MySQL 4 sollten doch in naher Zukunft eine wirklich gute Alternative zu den proprietären Lösungen darstellen, oder?

Was sagt Ihr dazu?

Viele Grüße
Andreas

  1. Darin steht unter anderem, dass mit der Kompatibilität zwischen PHP 4 und 5 bewußt gebrochen wird, halt mit den globalen Varblen, das $HTTP_*_VARS wohl nicht mehr unterstützt werden(!!!)...

    Hallo,

    ist schon mit php 4.2.x so !

    der grund ist  sicherheitsprobleme durch unvorsichtige programmierer, gern benutzes

    lg
    Ludwig

    1. Hi!

      ist schon mit php 4.2.x so !

      Da ist nur automatisch die Variable in der php.ini umgestellt, viele Leute haben ja daher, oder weil das Sicherheits-Problem bekannt war, mit $HTTP_*_VARS gearbeitet, aber wenn die in PHP5 kpl. abgeschaltet werden, dann wird das lustig(mehr oder weniger). Wobei, man könnte sich ja einfach ein kleines Script schreiben, welches auf allen Seiten $HTTP_GET_VARS durch $_GET ersetzt...
      Probleme gibt es halt bei den Seiten, wo ich keinen Zugriff auf die php.ini habe!

      Viele Grüße
      Andreas

  2. Hallo,

    http://www-user.tu-chemnitz.de/~meal/php/php5/

    Kennt sich jemand von Euch mit JSP aus? Wo liegen da die Vor- und Nachteile zu PHP? Was gibt es bei JSP für Serverseitige Voraussetzungen? Warum haben fast alle "mietbaren" Server PHP, oder wenigstens ASP, aber so gut wie keine JSP(mir sind jedenfalls keine bekannt!)? Ich hatte nämlich mal gehört, das JSP wirklich gut sein soll!? Außerdem sind eine Menge wirklich guter, großer und teurer Seiten in JSP programmiert!

    JSP/Servlets haben gegenueber PHP4 z.Zt. den Vorteil, dass man Business Logik und Praesentation besser trennen kann - z.B. mit benutzerdefinierten Tags. Aber auch mit Beans laesst sich schon einiges machen. Damit kann man den Mix aus HTML und Java Code besser trennen. Ist meiner Meinung nach auch für den Designer angenehmer mit wenig "fremden" Code vom Programmierer umgehen zu muessen.

    Zudem kann man so z.B. Datenbankabfragen besser auslagern. In den meisten Faellen werden in PHP, ASP oder auch ColdFusion die SQL-Statements direkt in der PHP (asp,cfml) Datei hinterlegt. Das ist für den Designer unschön und bei größeren Projekten wird es schwieriger den Ueberblick zu behalten.

    Nebenbei: Wie hinterlegt man in PHP am guenstigsten das Passwort fuer Datenbankverbindungen? Die Datenbankverbindung zusammen mit dem Passwort in einer Datei unterhalb des documentroot zu hinterlgen ist ja auch nicht so elegant, oder?

    Serversetitig benoetigt man für JSP/Servlets einen speziellen Web-Server mit JSP-Engine oder es wird ein vorhandener mit aufgesetzter Engine genutzt. Dazu zaehlen z.B. Tomcat, Resin (von caucho) oder auch JRUN.

    Es gibt immer noch wenige Hoster die JSP/Servlets in Ihr Angebot mir aufnehmen und diejenigen die es anbieten verlagen dafür (zurecht) mehr Geld. Such mal bei der webhostlist nach Anbietern mit Servlet Unterstützung. Dort wird man fuendig.

    Viele Grüße
    Andreas

    1. Hi Andreas,

      das hast du sehr gut auf dem Punkt gebracht. Wäre dein Kommentar schon online gewesen, als ich angefangen habe, mein zu verfassen, hätte ich mir die Arbeit sparen können ;-).

      Gruß,
      UlfL

    2. Hallo Namensvetter!

      JSP/Servlets haben gegenueber PHP4 z.Zt. den Vorteil, dass man Business Logik und Praesentation besser trennen kann - z.B. mit benutzerdefinierten Tags.

      Wie meinst Du das genau? Wenn irgendwo im Designder "Vorname" erscheinen soll, füge ich den in PHP mit <? $vorname ?> ein. Wie macht man das in JSP einfacher? Und der Restliche Code steht dann doch auch an anderer Steller in der Datei, genau wie in PHP, oder? Aber wenn ich z.B. in PHP eine aus einer DB generierte Tabelle erstellen will, dann ist das ein ganz schöner Mischmasch, die Abfrage und der PHP-Code schreibe ich dann halt vor die Tabelle, und die eine Zeile mit den Variablen muß ich mit einer Schleife umschließen. Ist unschön für ewinen Designer, aber geht das überhaupt andes in JSP?

      Aber auch mit Beans laesst sich schon einiges machen. Damit kann man den Mix aus HTML und Java Code besser trennen. Ist meiner Meinung nach auch für den Designer angenehmer mit wenig "fremden" Code vom Programmierer umgehen zu muessen.

      Nur kurz - was sind BEANS?

      Zudem kann man so z.B. Datenbankabfragen besser auslagern. In den meisten Faellen werden in PHP, ASP oder auch ColdFusion die SQL-Statements direkt in der PHP (asp,cfml) Datei hinterlegt. Das ist für den Designer unschön und bei größeren Projekten wird es schwieriger den Ueberblick zu behalten.

      Naja, das finde ich auch gar nicht so dumm! In eben dieser Datei beziehe ich nich ja auch auf die Abfrage, und wenn jetzt irgendjemand in einer anderen Datei was an der Afrage ändern könnte, dann funktioniert die Datei auf einmal nicht mehr! In welcher Form werden die Abfragen denn ausgelagert? Ich könnte die Abfrage ja auch in der Datei abfragen.inc speichern, die dann so aussieht:

      <?
      $warenkorb_auslesen="SELECT FROM warenkorb....";
      $bestellung_speichern="INSERT INTO bestellungen...";
      usw.
      ?>

      diese dann über

      include "abfrage.inc";

      in die eigentliche Datei einbinden und dann kann ich auf alle Abfragen zurückgreifen, wie ich will! Was ist da jetz der Unterschied zu JSP?

      Nebenbei: Wie hinterlegt man in PHP am guenstigsten das Passwort fuer Datenbankverbindungen? Die Datenbankverbindung zusammen mit dem Passwort in einer Datei unterhalb des documentroot zu hinterlgen ist ja auch nicht so elegant, oder?

      Ich mache das in einem Verzeichnes, welches nicht pber das Web erreichbar ist. Wenn Du das nicht hast einfach über ein anderes Verzeichnis, z.B. www.server.de/nicht_für_die_öffentlichkeit/
      und dieses dann über htaccess schützen, ist aber nicht 100%ig sicher, da htaccess nur bei web-zugriffen eingreift.

      Serversetitig benoetigt man für JSP/Servlets einen speziellen Web-Server mit JSP-Engine oder es wird ein vorhandener mit aufgesetzter Engine genutzt. Dazu zaehlen z.B. Tomcat, Resin (von caucho) oder auch JRUN.

      Ah, die namen habe ich schon gehört :-) Wie sind denn Solche Server im Vergleich zu Apache/PHP?

      Es gibt immer noch wenige Hoster die JSP/Servlets in Ihr Angebot mir aufnehmen und diejenigen die es anbieten verlagen dafür (zurecht) mehr Geld. Such mal bei der webhostlist nach Anbietern mit Servlet Unterstützung. Dort wird man fuendig.

      Ah, Danke! hab zwar erstmal genug mit PHP zu tun, aber vielleicht wird JSP ja mal ne Alternative!

      Vielen Dank!

      Grüße
      Andreas

      1. Hallo,

        Wie meinst Du das genau? Wenn irgendwo im Designder "Vorname" erscheinen soll, füge ich den in PHP mit <? $vorname ?> ein. Wie macht man das in JSP einfacher? Und der Restliche Code steht dann doch auch an anderer Steller in der Datei, genau wie in PHP, oder? Aber wenn ich z.B. in PHP eine aus einer DB generierte Tabelle erstellen will, dann ist das ein ganz schöner Mischmasch, die Abfrage und der PHP-Code schreibe ich dann halt vor die Tabelle, und die eine Zeile mit den Variablen muß ich mit einer Schleife umschließen. Ist unschön für ewinen Designer, aber geht das überhaupt andes in JSP?

        Mit reinem JSP natuerlich nicht. Damit das ganze komfortabler wird sollte man die Logik in Servlet, Beans und eigenen Tags kapseln.

        Den Code fuer eine DB Abfrage kann z.B. in eine Klasse ausgelagert werden. Der Designer erhaelt vom Programmierer die notwendigen Daten, die er einfach und fuer ihn verstaendlich in den HTML Code einbinden kann, z.B. durch:

        Kunden Name: <%= customer.getName() %>

        Diese Zeile soll z.B. den Namen vom Kunden ausgeben - fuer jemanden der HTML etwas versteht sicherlich gut nachzuvollziehbar.
        Klar, hier fehlt noch eine wenig Code vorher (1. eine Aufruf wie <jsp:useBean id="customer" scope="page" class="hier.liegt.die.klasse" /> und 2. der aufruf zum "durchlaufen" des resultset wie in php auch). Aber auch dies laesst sich mit benutzerdefinierten Tags noch eleganter loesen:

        <cust:show customer_id="13">
         Kunden Name: <%= name %>
         Ort: <%= ort %>
        </cust:show>

        Hier ist vorher einiges an Arbeit zu leisten, bis dies funktioniert.
        Sieht ein wenig wie ColdFusion aus, bietet aber IMHO nach den Vorteil das ich nicht wie im <cfqeury> die DB Namen, Passwort etc. hinterlegen muss [1]. Oder gibt es hierfuer mittlerweile eine bessere Loesung? Das ist unter Umstaenden ein Sicherheitsproblem. Denn wenn der Parser ausfaellt - egal ob in PHP oder ColdFusion - sieht der Nutzer im Browser Datenbankname und Passwort sofern man diese Informationen nicht "aus der Sichtweite" ausgelagert hat. Auch nicht schoen. Nebenbei: Es gibt in Zusammenhang mit dem IIS4 und aelterer CF Versionen ein Sicherheitsloch, bei dem es sehr einfach war sich diese Informationen anzeigen zu lassen (sofern kein Patch aufgespielt war).

        Nur kurz - was sind BEANS?

        Beans sind eben fuer diese Trennung von Logik und Design gut geeignet und machen die Wiederverwendung in verschiedenen Anwendungen moeglich. Ein Komponentenmodell halt.
        Details gibt es bei Sun http://java.sun.com/products/javabeans/ bzw. auf der faq Seite http://java.sun.com/products/javabeans/FAQ.html.

        Naja, das finde ich auch gar nicht so dumm! In eben dieser Datei beziehe ich nich ja auch auf die Abfrage, und wenn jetzt irgendjemand in einer anderen Datei was an der Afrage ändern könnte, dann funktioniert die Datei auf einmal nicht mehr! In welcher Form werden die Abfragen denn ausgelagert?

        mmhh, sollte mit den oben genannte Beispielen geklaert sein. Habe da einiges vorweg genommen...

        in die eigentliche Datei einbinden und dann kann ich auf alle Abfragen zurückgreifen, wie ich will! Was ist da jetz der Unterschied zu JSP?

        Wenn man will kann man es mit JavaServer Pages genau so loesen wie in PHP oder ASP auch. An dieser Stelle weise ich lieber mal drauf hin, dass man durch die JavaServer Pages XML- und HTML-Templates mit Java verwendet. Servlets, Beans und benutzerdefinierten Tag sind wiederum nicht in XML- und HTML-Templates zu verwenden. Servlets, JSP, Beans haben nur die Java Technologie gemeinsam. Einfacher ausgedrueckt: JSP entspricht etwa PHP, Servlets sind eher als Antwort auf CGI zu verstehen.

        Ich mache das in einem Verzeichnes, welches nicht pber das Web erreichbar ist. Wenn Du das nicht hast einfach über ein anderes Verzeichnis, z.B. www.server.de/nicht_für_die_öffentlichkeit/

        Das ist auch die mir einzig bekannte Moeglichkeit - die ich allerdings nicht fuer so schoen halte. Mit der genannten Resin Engine [2] kann man z.B. die Daten fuer DB Name, User, Passwort, Treiber etc. zentral in einer conf-Datei konfigurieren. Klar laesst sich das auch mit einer Datei in PHP loesen - ich habe halt nur ein unwohles Gefuehl dabei ;-)

        Ah, die namen habe ich schon gehört :-) Wie sind denn Solche Server im Vergleich zu Apache/PHP?

        Meist werde diese nur aufgesetzt. Resin ist meiner Meinung nach einfacher (als Tomcat) zu konfigurieren. Aber das ist alles eh nicht meine (Lieblings-)Welt ;-)

        Ah, Danke! hab zwar erstmal genug mit PHP zu tun, aber vielleicht wird JSP ja mal ne Alternative!

        Meiner Meinung nach kann man mit PHP kleine bis mittlere Projekte schnell realisieren. Bei groesseren sollte man sich die Java Technologie mal naeher anschauen. Das soll nicht bedeuten, dass man mit PHP keine umfangreichen Projekte realisieren kann.
        Ebenso halte ich ColdFusion unter Umstaenden (und dem noetigen Kleingeld) fuer eine Alternative.

        Viele Gruesse
        Andreas

        [1] sicherlich kann ich mir mit den Java Technologien ein Tag erstellen, dass eine Verbindung zur DB aufbaut: <db:conn dbname="dbname" query="select id,name from tabelle" user="ich" passwort="g-heim">
        [2] mit anderen JSP/Servlet Engine sicherlich auch

        1. kleine Korrektur...

          Servlets, Beans und benutzerdefinierten Tag sind wiederum nicht in XML- und HTML-Templates zu verwenden.

          Die Servlets sind nicht in XML- und HTML-Templates zu verwenden - die benutzerdefinierten Tags natuerlich schon.

  3. Hi Andreas,

    Aber alles in allem hören sich die Neuerungen alle ganz gut an, auch bzgl OOP. Da will man wohl auch mit JSP konkurrieren können.
    Kennt sich jemand von Euch mit JSP aus? Wo liegen da die Vor- und Nachteile zu PHP?

    JSP ist, wenn richtig gemacht, durchaus etwas komplizierter als PHP. Du hast es hier mit einer volllötigen OO-Programmiersprache zu tun, nicht eine "einfache" Skriptsprache wie PHP. Somit besteht eine JSP-Webanwendung meistens nicht nur aus JSPs, sondern auch aus kompilierte Java-Klassen.

    Was gibt es bei JSP für Serverseitige Voraussetzungen?

    Man braucht eine installierte JRE (Java Runtime Environment) und ein Servlet-Engine (ein Server wie z.B. Tomcat). Die Servlet-Engine ist (im Unterschied zu CGI) ein immerlaufender Prozess, der eintreffende Requests bearbeitet.

    Warum haben fast alle "mietbaren" Server PHP, oder wenigstens ASP, aber so gut wie keine JSP(mir sind jedenfalls keine bekannt!)?

    PHP ist nahe verwandt mit Perl, irgendwas womit sich viele Unix-Admins auskennen. OOP ist eine andere Ecke. Und ASP ist für die Windows-Welt.

    Aber PHP 5, Apache 2 und MySQL 4 sollten doch in naher Zukunft eine wirklich gute Alternative zu den proprietären Lösungen darstellen, oder?

    Apache und MySQL lassen sich auch hervorragend mit JSPs nutzen, viele der großen Projekte tun dies. Und Java ist alles andere als "proprietär" ;-).

    Gruß,
    UlfL

    1. Moin!

      Aber PHP 5, Apache 2 und MySQL 4 sollten doch in naher Zukunft eine wirklich gute Alternative zu den proprietären Lösungen darstellen, oder?

      Apache und MySQL lassen sich auch hervorragend mit JSPs nutzen, viele der großen Projekte tun dies. Und Java ist alles andere als "proprietär" ;-).

      PHP und MySQL sind genauso proprietär. Nur weil sie Open-Source sind, heißt das noch lange nicht, daß sie beliebig kompatibel sind. Wenn MySQL heftigst verwendet wird, kann man die SQL-Statements nicht mal eben auf eine andere Datenbank loslassen, weil die Syntax der Produkte sich doch unterscheidet (keine Ahnung, was ODBC da so zu leisten im Stande ist). Und PHP ist natürlich auch nur zu sich selbst kompatibel - wie jede andere Programmiersprache auch. PHP läuft nicht als Perl, als ASP, als C oder sonstwas. ;)

      Insofern ist das Wort "proprietär" eigentlich falsch gewählt in diesem Zusammenhang. Wer mit PHP und MySQL was bastelt, erhält hinterher eine Lösung, die nur mit PHP und MySQL funktioniert. Wer mit ASP und Access bastelt, kriegt etwas, was nur mit ASP und Access funktioniert. Wer JSP und Oracle zusammenstrickt, muß hinterher JSP und Oracle benutzen.

      - Sven Rautenberg

      1. Hi!

        Insofern ist das Wort "proprietär" eigentlich falsch gewählt in diesem Zusammenhang.[...]

        Hm, da habe ich wohl was falsch verstanden, ich dachte immer IIS, Windows, Oracle DB, UNIX... seinen 'proprietär', und Apache, Linux, PHP, MySQL eben nicht.

        [Zitat]"Proprietäre Software ist Software, die weder frei noch halbfrei ist. Ihre Weiterverbreitung oder Veränderung sind verboten oder verlangen von Ihnen, daß Sie eine Erlaubnis dafür benötigen oder sind so stark eingeschränkt, daß Sie sie effektiv nicht frei verändern oder verbreiten dürfen."[/Zitat]
        http://www.gnu.org/philosophy/categories.de.html#ProprietarySoftware

        Wie ist das sonst zu verstehen?

        Grüße
        Andreas

        1. Moin!

          Insofern ist das Wort "proprietär" eigentlich falsch gewählt in diesem Zusammenhang.[...]

          Hm, da habe ich wohl was falsch verstanden, ich dachte immer IIS, Windows, Oracle DB, UNIX... seinen 'proprietär', und Apache, Linux, PHP, MySQL eben nicht.

          [Zitat]"Proprietäre Software ist Software, die weder frei noch halbfrei ist. Ihre Weiterverbreitung oder Veränderung sind verboten oder verlangen von Ihnen, daß Sie eine Erlaubnis dafür benötigen oder sind so stark eingeschränkt, daß Sie sie effektiv nicht frei verändern oder verbreiten dürfen."[/Zitat]
          http://www.gnu.org/philosophy/categories.de.html#ProprietarySoftware

          Wie ist das sonst zu verstehen?

          Ich verstehe "proprietär" eigentlich immer im Sinne von "selbstausgedacht unter Mißachtung des Standards, und keiner sonst weiß, wie's geht". Sowas halt:
          http://www.interest.de/online/tkglossar/propriet_r.html

          Insofern ist PHP genauso proprietär wie alle anderen Sprachen auch: PHP definiert sich den Standard selbst, alles, was PHP kann, ist PHP (was ja aufgrund diverser Funktionen, die in älteren Versionen noch nicht oder anders funktionieren, für Probleme sorgen kann).

          Was in diesem Sinne nicht proprietär ist: Javascript, genauer: ECMA262. Das ist genormt. Genau deshalb hat Microsoft sein Javascript ja auch "JScript" genannt, um "proprietäre" Erweiterungen einzubauen.

          Das Javascript-DOM ist in der Vergangenheit auch heftigst proprietär gewesen: document.layers und document.all entsprachen keinem Standard. Erst die W3C-DOM-Definition (getElementById etc.) haben da Einheitlichkeit geschaffen.

          XML ist auch nicht proprietär. Es gibt einen Standard, und wenn alle sich dran halten, ist das eine prima Sache zum Datenaustausch. Nur ist XML eben kein Programm, sondern ein Datenformat - und Worddateien sind auf diesem Gebiet der beste Beweis, wie man proprietär sein kann, indem man irgendwann zu sich selbst inkompatibel wird.

          Ich würde also keinesfalls sagen: Was Open-Source ist, ist nicht proprietär, und was Closed-Source ist, ist immer proprietär. Auch mit Open-Source kann man wahnsinnig proprietär sein (vor allem dann, wenn sich Ablegerprojekte bilden, die die gleiche Basis nutzen, aber eigenständige Erweiterungen einbauen - wenn das nicht ins Gesamtprojekt zurückfließt, wird's übel). Und genauso kann Closed-Source ganz ohne proprietäre Elemente auskommen und einfach schlicht nur den Standard beachten, und nichts anderes.

          - Sven Rautenberg

      2. Hi Sven,

        Insofern ist das Wort "proprietär" eigentlich falsch gewählt in diesem Zusammenhang. Wer mit PHP und MySQL was bastelt, erhält hinterher eine Lösung, die nur mit PHP und MySQL funktioniert. Wer mit ASP und Access bastelt, kriegt etwas, was nur mit ASP und Access funktioniert. Wer JSP und Oracle zusammenstrickt, muß hinterher JSP und Oracle benutzen.

        Hier wäre man mit JSPs natürlich im Vorteil, weil man hier den ganzen SQL-Kram in einzelne Klassen kapselt (oder kapseln sollte). Will man einen anderen Datenbank einsetzen, schreibt man eine neue SQL-Klasse, die übrige Anwendung muss nicht verändert werden.

        Du hast natürlich recht darin, dass die einzelnen Programmiersprachen unter einander nicht kompatibel sind. Das wird noch eine Weile dauern, bis eine in einer beliebigen Sprache geschriebenen Anwendung in einer beliebigen Laufzeitumgebung funktioniernen wird. Auch wenn Microsofts .NET ein Schritt in die Richtung ist.

        Gruß,
        UlfL