Smarty und PHP5
Tom
- php
Hello,
drei Fragen:
1. Ist Smarty 2.6.24 die derzeit neueste Smarty-Version, oder habe ich as übersehen?
2. Ist diese Smarty-Version überhaupt unter PHP5 lauffähig?
3. Was ist mit einem "klassischen Constructor", also einem, der genauso heißt,
wie seine Klasse, unter PHP5? Wird der dort zur einfachen Funktion?
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
Hello Ingrid,
- Was ist mit einem "klassischen Constructor", also einem, der genauso heißt,
wie seine Klasse, unter PHP5? Wird der dort zur einfachen Funktion?
Das schreibt Andy Gutmans dazu:
In PHP 4, instead of using
__construct()
as the constructor’s name, you
had to define a method with the classes’ names, like C++. This still works with
PHP 5, but you should use the new unified constructor naming convention for
new applications.
Durch Versuch konnte ich feststellen, dass der alte Konstruktor nur aufgerufen wird, wenn kein neuer vorhanden ist. Ist das abgesichert? Darüber konnte ich nichts finden, insbesondere, wie es in Zukunft werden wird...
Es gab doch irgendwo eine Zusammenstellung der Änderungen von PHP4 zu PHP5, was die OOP betrifft.
Kann mir jemand den Link dazu geben?
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
Nochmal hallo,
Es gab doch irgendwo eine Zusammenstellung der Änderungen von PHP4 zu PHP5, was die OOP betrifft.
Kann mir jemand den Link dazu geben?
Für den Anfang vielleicht:
* Klassen und Objekte (PHP 4)
* Klassen und Objekte (PHP 5)
Ale×
(Hallo|Hi(ho)|Tag und Mahlzeit) Tom,
Durch Versuch konnte ich feststellen, dass der alte Konstruktor nur aufgerufen wird, wenn kein neuer vorhanden ist. Ist das abgesichert? Darüber konnte ich nichts finden, insbesondere, wie es in Zukunft werden wird...
Es gab doch irgendwo eine Zusammenstellung der Änderungen von PHP4 zu PHP5, was die OOP betrifft.
Kann mir jemand den Link dazu geben?
Generell:
Änderungen von 4 zu 5.0.x: http://de.php.net/manual/en/migration5.php
Inkompatibilitäten zu 4: http://de.php.net/manual/en/migration5.incompatible.php
OO-spezifisch:
"Object model" in PHP5: http://de.php.net/manual/en/migration5.oop.php
Konstruktuoren und Desktruktoren in PHP5: http://de.php.net/manual/en/language.oop5.decon.php
Da steht (u. A.):
For backwards compatibility, if PHP 5 cannot find a __construct() function for a given class,
it will search for the old-style constructor function, by the name of the class.
Effectively, it means that the only case that would have compatibility issues is
if the class had a method named __construct() which was used for different semantics.
MffG
EisFuX
Hello EisFuX,
ja, nee is klar :-)
Ist zwar alles schon in die Richtung, in die ich wollte, aber der zündende Link war noch nicht dabei.
Ich habe schon das Archiv durchgeforstet, denn ich bin sicher, dass wir das hier disktuiert haben vor laaaanger Zeit. Damals hatte jemand eine tolle Gegenüberstellung und die Änderungen usw. verlinkt.
War so eine Kochrezept: Was muss ich machen, wenn die Klamotten auf PHP4 und auf PHP5 optimal laufen sollen. Aber irgendwie finde ich die nicht wieder raus...
Ich glaube, ich hätte sie damals 1ieber abspeichern und nicht ausdrucken sollen *g*
Mich interessiert dabei: Was muss ich beachten, wenn ich von PHP4 auf PHP5 migrieren will und dabei die alten gegen neue Syntax und die Möglichkeiten austauaschen/ergänzen will?
mit http://de.php.net/manual/en/migration5.incompatible.php warst Du da schon ziemlich dicht dran. Ich wollte schon jubeln. Aber ich glaube, es war nicht aus der Original-Doku.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
echo $begrüßung;
Mich interessiert dabei: Was muss ich beachten, wenn ich von PHP4 auf PHP5 migrieren will und dabei die alten gegen neue Syntax und die Möglichkeiten austauaschen/ergänzen will?
In einem Satz: Schalte E_STRICT ein und beseitige alle Ursachen für die Meldungen.
Wichtig ist, zu dem was durch die Syntax-Möglichkeiten sichtbar ist, dass Objekte nun per Referenz und nicht mehr wie alle anderen Variablentypen per Kopie übergeben werden. Es sei denn, man legt mit clone explizit eine Kopie an.
echo "$verabschiedung $name";
Hallo Tom,
- Ist Smarty 2.6.24 die derzeit neueste Smarty-Version [...] ?
Ja, scheint so zu sein.
- Ist diese Smarty-Version überhaupt unter PHP5 lauffähig?
2.6.22 ist es jedenfalls (2.6.24 habe ich noch nicht im Einsatz).
- Was ist mit einem "klassischen Constructor", also einem, der genauso heißt, wie seine Klasse, unter PHP5? Wird der dort zur einfachen Funktion?
Das ist abwärtskompatibel und funktioniert nach wie vor. Auch var $meineEigenschat;
geht noch (wird wie public behandelt).
Grüße
Ale×
hello und guten Morgen Ale×,
- Ist Smarty 2.6.24 die derzeit neueste Smarty-Version [...] ?
Ja, scheint so zu sein.
Dank. Das hatte ich gesehen. Es gibt da wohl schon eine alpha von Version 3.x, aber dazu war ich gestern schon zu müde, die noch irgendwo draufzuspielen.
- Ist diese Smarty-Version überhaupt unter PHP5 lauffähig?
2.6.22 ist es jedenfalls (2.6.24 habe ich noch nicht im Einsatz).
Was mich daran wundert(e) ist, dass es doch in der OOP zwischen PHP4 und PHP5 gravierende Unterschiede gibt. Ich konnte bisher nicht entdecken, dass das irgendwo abgefangen wird.
- Was ist mit einem "klassischen Constructor", also einem, der genauso heißt, wie seine Klasse, unter PHP5? Wird der dort zur einfachen Funktion?
Das ist abwärtskompatibel und funktioniert nach wie vor. Auch
var $meineEigenschat;
geht noch (wird wie public behandelt).
So ganz steige ich noch nicht durch, wann es Probleme gibt mit den Unterschieden.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
So ganz steige ich noch nicht durch, wann es Probleme gibt mit den Unterschieden.
PHP 4 kann ja noch keine echte™ Objekt-Orientierung mit allen Schikanen. Wenn ich mich richtig erinnere schimpft sich das "objektbasiert". So eine objektbasierte PHP-4-Anwendung läuft IMHO auch noch problemlos unter PHP 5.
Ale×
n'abend,
Dank. Das hatte ich gesehen. Es gibt da wohl schon eine alpha von Version 3.x, aber dazu war ich gestern schon zu müde, die noch irgendwo draufzuspielen.
Smarty3 ist zwar schon relativ stabil - den produktiven Einsatz würde ich jedoch noch nicht empfehlen. Es tauchen immer wieder noch Kleinigkeiten auf, die sehr verwirrend sein können, wenn du nicht weißt was an welcher Stelle eigentlich passieren sollte. Die Docs sind momentan auch noch nicht wirklich brauchbar. Smarty3 ist aber auf einem sehr sehr guten Weg... reinschauen lohnt sich.
weiterhin schönen abend...
Hello,
Smarty3 ist zwar schon relativ stabil - den produktiven Einsatz würde ich jedoch noch nicht empfehlen. Es tauchen immer wieder noch Kleinigkeiten auf, die sehr verwirrend sein können, wenn du nicht weißt was an welcher Stelle eigentlich passieren sollte. Die Docs sind momentan auch noch nicht wirklich brauchbar. Smarty3 ist aber auf einem sehr sehr guten Weg... reinschauen lohnt sich.
Und hat sich das nun von "PHP4-OOP" vollkommen gelöst und nutzt nur noch die neue Syntax?
Ich steige da noch nicht ganz durch.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
Hallo,
Und hat sich das nun von "PHP4-OOP" vollkommen gelöst und nutzt nur noch die neue Syntax?
Ja, sieht ganz so aus.
Ale×
n'abend,
Und hat sich das nun von "PHP4-OOP" vollkommen gelöst und nutzt nur noch die neue Syntax?
Ich steige da noch nicht ganz durch.
Ich weiß ehrlich gesagt nicht was du im Jahre des Herrn 2009 noch mit PHP4 willst. Nutzt du auch noch Netscape 4? Bist du Computergeschichtsforscher?
Das sogenannte OOP in PHP4 ist vollkommen für die Tonne. Das ist kein OOP. PHP4 kann keine Kapselung (Attribute/Methoden nach außen sichtbar [public], nur für die Klasse sichtbar [private], für Klasse und Erben sichtbar [protected]). PHP4 kann keine Interfaces. PHP4 kann eigentlich gar nichts. PHP4 ist offiziell tot.
Smarty3 setzt vollkommen auf PHP5 auf. Dementsprechend werden natürlich auch die PHP5 OOP Dinge eingesetzt. Dementsprechend wird Smarty3 *nicht* auf PHP4 Systemen laufen. Smarty3 wird jedoch keine Neuerungen aus PHP5.3 einsetzen. Es wird also erstmal keine Namespaces geben.
weiterhin schönen abend...
Hello,
Und hat sich das nun von "PHP4-OOP" vollkommen gelöst und nutzt nur noch die neue Syntax?
Ich steige da noch nicht ganz durch.Ich weiß ehrlich gesagt nicht was du im Jahre des Herrn 2009 noch mit PHP4 willst.
Ich auch nicht. Was bringt Dich auf den Gedanken, dass ich Wert darauf lege?
Nutzt du auch noch Netscape 4?
Nein, aber ich habe es noch zur Verfügung. Museumsstückchen einschalten, Netscape starten, fertig :-)
Bist du Computergeschichtsforscher?
Manchmal ja. Gutachten erfordern das von zeit zu Zeit.
Das sogenannte OOP in PHP4 ist vollkommen für die Tonne.
Sind dann Produkte, die für PHP4 (>= 4.0.6) geschreiben sind, auch für die Tonne?
Das ist kein OOP. PHP4 kann keine Kapselung (Attribute/Methoden nach außen sichtbar [public], nur für die Klasse sichtbar [private], für Klasse und Erben sichtbar [protected]). PHP4 kann keine Interfaces. PHP4 kann eigentlich gar nichts. PHP4 ist offiziell tot.
*ohne Worte*
Smarty3 setzt vollkommen auf PHP5 auf. Dementsprechend werden natürlich auch die PHP5 OOP Dinge eingesetzt. Dementsprechend wird Smarty3 *nicht* auf PHP4 Systemen laufen. Smarty3 wird jedoch keine Neuerungen aus PHP5.3 einsetzen. Es wird also erstmal keine Namespaces geben.
das wiederum war nun eine brauchbare Aussage.
Sie bringt mich zu der Annahme, dass es sich nicht lohnt, mit Smarty < 3.x noch ein neues Projekt zu beginnen.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
Hallo,
Sie bringt mich zu der Annahme, dass es sich nicht lohnt, mit Smarty < 3.x noch ein neues Projekt zu beginnen.
...oder ob es sich überhaupt lohnt, Smarty zu verwenden. IMHO braucht man eine Template-Engine mit eigener Syntax nur, wenn die Templates kein ausführbares PHP enthalten dürfen - z.B. wenn die Benutzer eigene Templates hochladen können oder die Templates aus anderen unvertrauenswürdigen Quellen kommen. Ansonsten ist PHP ja selbst schon ein Template-System.
Ale×
Hello,
Sie bringt mich zu der Annahme, dass es sich nicht lohnt, mit Smarty < 3.x noch ein neues Projekt zu beginnen.
...oder ob es sich überhaupt lohnt, Smarty zu verwenden. IMHO braucht man eine Template-Engine mit eigener Syntax nur, wenn die Templates kein ausführbares PHP enthalten dürfen - z.B. wenn die Benutzer eigene Templates hochladen können oder die Templates aus anderen unvertrauenswürdigen Quellen kommen. Ansonsten ist PHP ja selbst schon ein Template-System.
Ja. Das ist die Ursache.
Ich habe ein eigenes kleines passives Template-System, das sehr genau Darstellung, Datenaufbereitung für die Darstellung, Datenverarbeitung, Datenhaltung, usw. trennt.
Beim Rückweg aus der Darstellung zur Verarbeitung hapert es aber noch. Deshalb habe ich mir Smarty (nach Jahren) nochmal reingeholt...
Und bei der Unterstützung für den Designer fehlt es auch noch. Ich möchte erreichen, dass der Designer z.B. innerhalb eines <p> keine Objekte platzieren kann, die dort nicht hineingehören... usw.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
Beim Rückweg aus der Darstellung zur Verarbeitung hapert es aber noch. Deshalb habe ich mir Smarty (nach Jahren) nochmal reingeholt...
Was hat Smarty damit zu tun?
Ich möchte erreichen, dass der Designer z.B. innerhalb eines <p> keine Objekte platzieren kann, die dort nicht hineingehören... usw.
Das kann er doch auch mit Smarty!?
Ale×
Hello,
Beim Rückweg aus der Darstellung zur Verarbeitung hapert es aber noch. Deshalb habe ich mir Smarty (nach Jahren) nochmal reingeholt...
Was hat Smarty damit zu tun?
bevor ich das Rad doch nochmal neu erfinde, schaue ich immer lieber, sie es Andere machen. Aber das war bisher wenig nützlich. Ich bin nur darauf gestoßen, dass Smarty alles andere ist, als "MVC"-verträglich.
Ich möchte erreichen, dass der Designer z.B. innerhalb eines <p> keine Objekte platzieren kann, die dort nicht hineingehören... usw.
Das kann er doch auch mit Smarty!?
Genau. Darum will ich es ja nicht genauso verknoten, wie Smarty.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
echo $begrüßung;
Ich bin nur darauf gestoßen, dass Smarty alles andere ist, als "MVC"-verträglich.
Das ist Unfug. Smarty ist eine Template-Engine, die, wie jedes andere System, das Daten entgegennimmt und eine Ausgabe erstellt, sehr wohl im View-Part eines nach dem MVC-Pattern aufgebautem System eingesetzt werden kann.
echo "$verabschiedung $name";
n'abend,
»» Ich weiß ehrlich gesagt nicht was du im Jahre des Herrn 2009 noch mit PHP4 willst.
Ich auch nicht. Was bringt Dich auf den Gedanken, dass ich Wert darauf lege?
Die Frage las sich so.
»» Das sogenannte OOP in PHP4 ist vollkommen für die Tonne.
Sind dann Produkte, die für PHP4 (>= 4.0.6) geschreiben sind, auch für die Tonne?
Nicht für die Tonne, aber definitiv veraltet.
»Support for PHP 4 has been discontinued since 2007-12-31. Please consider upgrading to PHP 5.«
PHP4 wurde vor anderthalb Jahren eingestellt. Noch Fragen?
»» Smarty3 setzt vollkommen auf PHP5 auf. Dementsprechend werden natürlich auch die PHP5 OOP Dinge eingesetzt. Dementsprechend wird Smarty3 *nicht* auf PHP4 Systemen laufen. Smarty3 wird jedoch keine Neuerungen aus PHP5.3 einsetzen. Es wird also erstmal keine Namespaces geben.
das wiederum war nun eine brauchbare Aussage.
Sie bringt mich zu der Annahme, dass es sich nicht lohnt, mit Smarty < 3.x noch ein neues Projekt zu beginnen.
Ja und nein.
Smarty3 ist - was die Innereien angeht - von Smarty2 grundverschieden. Was die API angeht hat sich jedoch nicht so arg viel verändert. Was die Template-Syntax angeht haben sich auch keine fundamentalen Änderungen ergeben. Wenn du aber eigene Plugins für Smarty schreiben willst/musst, würde ich tatsächlich auf Smarty3 warten. Die Umgebung für Plugins ist in Smarty3 wesentlich ausgereifter, komfortabler und um ein vielfaches mächtiger.
Wenn du jetzt mit der Entwicklung anfängst und dein Projekt in den nächsten Wochen nicht in die Produktion geht, könntest du dich allerdings heute schon - einigermaßen ruhigen Gewissens - an Smarty3 heranschmeißen.
weiterhin schönen abend...