nicht angemeldet
Was macht ein gutes Script aus?
0 0 0 Mailtexte extern speichern
0 0
Was macht ein gutes Script aus?
Hallo SELF-Forum-Team,
ich habe gerade Perl gelernt und bin begeistert von den Möglichkeiten, die diese Programmiersprache bietet. Mein Script wächst und wächst. Es verarbeitet Daten aus verschiedenen Formularen auf meiner Webseite (Newsletter-Anmeldungen, Kontakt-Formulare, etc.) und verschickt daraufhin Mails, speichert die Daten in .txt-Dateien, zeigt "Danke"-Seiten mit eingeparsten Namen an und kümmert sich auch noch um das automatische Follow-Up. In meiner Planung kommt später noch eine POP3-Abfrage hinzu (auch wieder mit entsprechenden Aufgaben).
Inzwischen hat mein Script 54 KB. Sämtliche html- und mail-templates sind externe .txt-Dateien, ist also nur der Programmcode.
Nun stellt sich mir die Frage, bis zu welcher Größe so ein Script sinnvoll ist, bzw. ab wann man das Script teilen sollte, damit es nicht zu groß wird.
Dann ist es so, das dieses Script recht häufig aufgerufen wird. Ist es da besser, mehrere Scripts nebeneinander laufen zu haben oder spielt das keine Rolle, wenn immer dasselbe Script alles bearbeitet?
Eine weitere Möglichkeit, über die ich nachdenke, ist auf meiner Webseite dynamische Inhalte, also z.B. Namen, anzeigen zu lassen. Ich wüßte, wie ich das mit Perl lösen kann: Jede Seite ruft statt einer .html-Seite mein Script auf und das erzeugt dann die .html-Seite mit den eingeparsten Namen. Ist das schlau, sowas zu machen, oder überfordere ich den Server damit (ca. 700 Besucher täglich)? Sollte das "Parse-Script" dann ausgelagert sein von dem "Mail-Script"?
Eine weitere Frage ist, ob und wenn ja wie ich die CPU-Sekunden messen kann, die mein Script verbraucht. Mein Provider hat ein timeout, nach dem das Script getötet wird. Allerdings ohne mich zu benachrichtigen. Insofern wüßte ich gerne, wie dicht mein Script an das Limit heranreicht, um das "Töten" zu vermeiden. Gibt es da vielleicht so eine Art "Task-Manager" für den Server, mit CPU-Auslastungs- und Speicherverbrauchs-Anzeige?
Je mehr ich über Perl lerne, desto mehr Ideen habe ich, die ich gerne umsetzen möchte. So wird das gesamte Projekt immer umfangreicher und komplexer. Bisher speichere ich die Daten der Kontakte in .txt-Dateien ab, die mittels .htaccess vor Zugriffen geschützt sind. Noch ist alles recht überschaubar. Ab wann macht es Sinn, eine "richtige" Datenbank wie MySQL einzusetzen? Wo liegen die Vorteile? Wie verhält es sich mit der Rechenzeit gegenüber einem Textdateien durchsuchenden Perl-Script?
Jau, das waren jetzt viele Fragen, die mir auf den Nägeln brennen. Ich freue mich auf die Antworten!
Muchas Gracias,
JOhnnY
-
Zusatzfrage:
Wo liegen eigentlich die Unterschide zwischen Perl und PHP? Welche Sprache eignet sich für welche Aufgabe?
Muchas Gracias,
JOhnnY-
Halihallo Johnny again
Wo liegen eigentlich die Unterschide zwischen Perl und PHP? Welche Sprache eignet sich für welche Aufgabe?
*grrrrr!* => </archiv/> ;)
Viele Grüsse
Philipp
-
Halihallo Johnny again
Wo liegen eigentlich die Unterschide zwischen Perl und PHP? Welche Sprache eignet sich für welche Aufgabe?
*grrrrr!* => </archiv/> ;)
Viele Grüsse
Philipp
sorry, war so im Frage-Rausch... :)
-
-
-
Hallo,
Eine weitere Frage ist, ob und wenn ja wie ich die CPU-Sekunden messen kann, die mein Script verbraucht.
use Benchmark;
my $t0 = new Benchmark;... #dein Code
my $t1 = new Benchmark;
my $time_diff = timediff($t1,$t0);
$time_diff = timestr($time_diff);print $time_diff;
Gruß Markus
--
alles wird gut... -
Hallo!
Inzwischen hat mein Script 54 KB. Sämtliche html- und mail-templates sind externe .txt-Dateien, ist also nur der Programmcode.
Dazu hätte ich mal eie Frage. Verschickst Du so auch personifizierte Mails, also mit individueller Anrede, oder individuellem Link? Denn das mache ich fast nur und habe deshalb eigentlich alle mails fest kodiert im Quelltext stehen, wenn nicht gerade besonders schön ist, vor allem wenn was geändert werden soll. Aber wenn man keine standard-mails verschicken will/kann, dann braucht man da halt einen Parser, der entsprechende Variablen ersetzt. Das Problem an dieser Stelle ist nur, dass die mails so verschieden sind, mal brauche ich sowas wie "sehr geehrter Herr XY", mal muß ich z.B. eine komplette Bestellung bestätigen, dann wieder einen individuellen Link schicken, oder ein zufällig erzeugtes Passwort... wie bekommt man das sinnvoll unter einen Hut?
Gerade bei Dingen wie Bestätigung einer Bestellung wird das ganze schwierig, da die Daten schonmal unterschiedlich sein können, oder teilweise nicht notwendige Daten nicht mitgeschickt werde sollen, oder je nach gewähter Zahlungsoption verschiedene Texte ausgegeben werden sollen, so würde der Parser doch wieder recht komplex. Außerdem besteht hier noch das Problem, das man eine ganze Liste mit bestellten Artikeln angeben muß, deren Länge man vorher nicht kennt.
Oder hat das bei solchen Sachen keinen Sinn und man sollte sowas besser fest kodieren, und nur einfache mails mit verschiedener Anrede oder einem Link auf diese Weise parsen und extern speichen?Viele Grüße
Andreas-
Hi Andreas,
dazu hätte ich mal eie Frage. Verschickst Du so auch personifizierte Mails, also mit individueller Anrede, oder individuellem Link?
-- yepp...Denn das mache ich fast nur und habe deshalb eigentlich alle mails fest kodiert im Quelltext stehen, wenn nicht gerade besonders schön ist, vor allem wenn was geändert werden soll. Aber wenn man keine standard-mails verschicken will/kann, dann braucht man da halt einen Parser, der entsprechende Variablen ersetzt.
--- ja, ist doch kein Problem...Das Problem an dieser Stelle ist nur, dass die mails so verschieden sind, mal brauche ich sowas wie "sehr geehrter Herr XY", mal muß ich z.B. eine komplette Bestellung bestätigen, dann wieder einen individuellen Link schicken, oder ein zufällig erzeugtes Passwort... wie bekommt man das sinnvoll unter einen Hut?
--- die Daten einlesen, das Mail einlesen und dann z.B. %anrede% mit der aus der Datenbank gelesenen anrede ersetzen. Klappt wunderbar... Gesamte message einlesen und dann am besten eine Subroutine &parsetext($message) erstellen, die dann die Felder ersetzt...Gerade bei Dingen wie Bestätigung einer Bestellung wird das ganze schwierig, da die Daten schonmal unterschiedlich sein können, oder teilweise nicht notwendige Daten nicht mitgeschickt werde sollen, oder je nach gewähter Zahlungsoption verschiedene Texte ausgegeben werden sollen, so würde der Parser doch wieder recht komplex.
--- eigentlich nicht. Du hast dann in der Mail z.B. %zahlungsoption%, welches vom Parser mit der Variable $zahlungsoption ersetzt wird und die hat je nach Zustand einen anderen Wert. Entsprechend geht das auch mit Links.
Außerdem besteht hier noch das Problem, das man eine ganze Liste mit bestellten Artikeln angeben muß, deren Länge man vorher nicht kennt.
--- s.o.Oder hat das bei solchen Sachen keinen Sinn und man sollte sowas besser fest kodieren, und nur einfache mails mit verschiedener Anrede oder einem Link auf diese Weise parsen und extern speichen?
--- also ich sehe keinen Hinderungsgrund. Ich parse z.B. javascript-Funktionen in die html-templates - das geht auch problemlos...
Alles Liebe
JohnnY-
Hallo!
--- die Daten einlesen, das Mail einlesen und dann z.B. %anrede% mit der aus der Datenbank gelesenen anrede ersetzen. Klappt wunderbar... Gesamte message einlesen und dann am besten eine Subroutine &parsetext($message) erstellen, die dann die Felder ersetzt...
Das ist auch nicht das Problem. Aber eigentlich hast Du Recht, man muß sich nur einmal die Arbeit machen alle Variablen in den Parser aufzunehmen, welche Reihenfolge verwendest Du denn? Parst Du erst den Mailtext, und der Parser holt sich dann die Daten selbst? Aber das ist alles nicht ganz so optimal, wenn ich die Daten aus einer Datenbank holfe, dann würde es bei der Verwendung von einem Parser für das gesamte Projekt nur Sinn machen, wenn er sich alle Variablen einzelnd holt, also %Anrede%, %Name%... alles als eine neue SQL-Abfrage, normalerweise mache ich das ganze mit einer einzigen Abfrage in der ich alle Felder abfrage, nur läßt sich sowas nicht in den Parser packen, da die Datenbank-Abfragen _sehr_verschieden sind. Außerdem verwende ich teilweise JOINs über mehrere Tabellen, das alles kann der Parser nicht wissen. Also muß ich dem Parser die rohen Daten vorher zur Verfügung stellen, und da wird das ganze wieder komplizierter, dann brauche ich eine Schnittstelle zum Parser...
--- eigentlich nicht. Du hast dann in der Mail z.B. %zahlungsoption%, welches vom Parser mit der Variable $zahlungsoption ersetzt wird und die hat je nach Zustand einen anderen Wert.
Und wo speichere ich welchen Wert die Variable $zahlungsoption hat?
Außerdem besteht hier noch das Problem, das man eine ganze Liste mit bestellten Artikeln angeben muß, deren Länge man vorher nicht kennt.
--- s.o.Was heißt da s.o.? Also eine Variable %liste% verwenden und der Parser macht daraus die richtige Liste oder wie? Am Ende wird doch wieder alles mehr oder weniger gemischt, vielleicht sollte man für bestimmte mails einfach mehrere Templates für bestimmte Teile haben, und im Script alles zusammensetzen, naja.
Grüße
Andreas -
use Mosche;
--- eigentlich nicht. Du hast dann in der Mail z.B. %zahlungsoption%, welches vom Parser mit der Variable $zahlungsoption ersetzt wird
Benutze hier nicht die Variable $zahlungsoption, sondern zB $text{zahlungsoption}. Das ist einfacher von der Perl-Logik, und auch sicherer. Was passiert zB, wenn du in irgendeiner Variable ein Passwort gespeichert hast, und dann %password% erscheint? Sicherheitslücke. Mit dem Hash kannst du den Zugriff genau regeln.
use Tschoe qw(Matti);
--
$a=n(1001010);print chr($a+=$_)for(0,43,-2,1,-84,65,13,1,5,
-12,-3,13,-82,48,21,13,-6,-76,72,-7,2,8,-6,13,-104);sub n{
$b=0;$_=0;for($c=length$_[0];$c;--$c){$_+=_($b)if substr$_
[0],$c-1,1;$b++;}$_}sub _{($d)=@_;for($e=1;$d--;$e*=2){}$e}
-
-
-
use Mosche;
Inzwischen hat mein Script 54 KB. Sämtliche html- und mail-templates sind externe .txt-Dateien, ist also nur der Programmcode.
Nun stellt sich mir die Frage, bis zu welcher Größe so ein Script sinnvoll ist, bzw. ab wann man das Script teilen sollte, damit es nicht zu groß wird.
Frage: Warum solltest du ein Script haben, welches verschiedene Aufgaben erledigt?
Antwort: um gemeinsam benutzte Prozeduren lokal zu halten.
Lösung: gemeinsam benutzte Prozeduren in ein Modul auslagern. Das bewirkt, dass du deine Prozeduren schön zentral lagern kannst (Änderungen sind einfach), allerdings auch, dass deine Scripte nicht größer sind als unbedingt notwendig.Prinzipiell halte ich es so: ein Script ist für _eine_ Aufgabe zuständig, zB formmail. Auch wenn es verschiedene Phasen kennt (zB bei Newsletter-Anmeldungen mit Aktivierung durch E-mail), so lager ich das zentral in einem Script. Sämtliche Prozeduren, die von mehr als einem Script benutzt werden, lager ich zentral (inklusive der gesamten Konfiguration, zB Verzeichnispfade ...).
use Tschoe qw(Matti);
--
$a=n(1001010);print chr($a+=$_)for(0,43,-2,1,-84,65,13,1,5,
-12,-3,13,-82,48,21,13,-6,-76,72,-7,2,8,-6,13,-104);sub n{
$b=0;$_=0;for($c=length$_[0];$c;--$c){$_+=_($b)if substr$_
[0],$c-1,1;$b++;}$_}sub _{($d)=@_;for($e=1;$d--;$e*=2){}$e} -
Hy Johnny,
so wie es scheint hast du noch viel vor. Wenn du Perl im grösseren umfang einsetzen willst würde ich mir mal http://www.masonhq.com/
anschauen.
(trotz der com adresse ist mason 100% open-source)Mason ist eine möglichkeit perl direkt in html-seiten/templates einzubauen und viel, viel, mehr.
Mason ist ein eigenes perl-modul und eigentlich dazu gedacht in die apache configuration mit eingebaut zu werden. Es geht aber auch ohne.
Perl erfordert grundsätzlich etwas mehr kontrolle über den Server. O.k. das ist untertrieben. Ich finde das man mit Perl erst richtig spass haben kann auf einem Dedicatet-Server.
Ich bin vor etwa einem Jahr auf Mason gestossen und wiegere mich inzwischen unter einer anderen "Perl-Umgebung" zu arbeiten.
So nun aber zu deinen Fragen:
54kb -- viel zu viel ! Ich hoffe du hast das "Kamel" Buch -
bau dir dein eigenes Modul/Module. oder einige Scripte. Alle Scripte die URL argumente mit reihen weisen ifelse auswerten sind seeehr suspekt.Dynamische Inhalte: Entweder du schaust mal mein (lieblings) HTML::Mason an oder für kleine Sachen HTML::Embperl. Viel besser.
Rechenzeit: es gibt ein perl modul namens Benchmark - ungefähr so:
use Benchmark;
wurde schon beantwortetLetztendlich ist Perl jedoch ein InTime Compiler - d.h. jedesmal wenn dein Script starten wird es _komplet_ compiliert. Das compilierte Script wird vom WebServer (wenn er vernüftig configuriert ist) eine ganze weile im RAM gehalten. Das abschiessen der Scripte von deinem Provider ist eher eine sicherheits masname in bezug auf Endlosschleifen o.ä.
Selbst mit einem 54kb Script kannst du sowas normaler weise nicht schocken.
Richtige Datenbanken: Sobald du schreiben willst oder du "RandomAccess" benötigst.
Man kommt mit normalen .txt Files erstaunlich lange zurecht. Es wird allerdings ganz schnell bösse wenn du nicht "anhängen" willst sondern "reinschieben", grundsätzlich ist schreiben ziemlich unangenehm. Auch wenn die Datei etwas grösser wird und du nicht die ganze Datei ausgeben willst sondern nur Zeile 107 wird es je nach deinen zugriffs Zahlen sinvoll eine DB einzusetzen.
Trotzdem Perl ist dafür entwickelt worden Text dateien zu durchsuchen - aber es gibt da Grenzen.Schlussrede:
Ich habe glücklicherweise einen eigenen Server.
Perl überragende Macht liegt darin an allem rumzuspielen was in seiner reichweite liegt. Diese wird gestützt von www.cpan.org.
Also siehe zu das du die richtigen Module an den Start bekommst. Und alles ist ganz easy going.Wenn dir sich das nicht langfristig bietet... nimm PHP.
-
use Mosche;
so wie es scheint hast du noch viel vor. Wenn du Perl im grösseren umfang einsetzen willst würde ich mir mal http://www.masonhq.com/
anschauen.http://www.masonhq.com ist tasächlich ein sehr schönes Modul, ich benutze es auch und kann es nur empfehlen, allerdings ...
Letztendlich ist Perl jedoch ein InTime Compiler - d.h. jedesmal wenn dein Script starten wird es _komplet_ compiliert. Das compilierte Script wird vom WebServer (wenn er vernüftig configuriert ist) eine ganze weile im RAM gehalten. Das abschiessen der Scripte von deinem Provider ist eher eine sicherheits masname in bezug auf Endlosschleifen o.ä.
Meines Wissens wird das Script nur mit mod_perl im Speicher gehalten, und dann bleibt es doch da so lange, bis es abgeschossen wird. Und dann (wenn man tatsächlich schon ein bestehendes Script verbessern will, sollte man mod_perl verwenden).
use Tschoe qw(Matti);
--
$a=n(1001010);print chr($a+=$_)for(0,43,-2,1,-84,65,13,1,5,
-12,-3,13,-82,48,21,13,-6,-76,72,-7,2,8,-6,13,-104);sub n{
$b=0;$_=0;for($c=length$_[0];$c;--$c){$_+=_($b)if substr$_
[0],$c-1,1;$b++;}$_}sub _{($d)=@_;for($e=1;$d--;$e*=2){}$e}-
Meines Wissens wird das Script nur mit mod_perl im Speicher gehalten, und dann bleibt es doch da so lange, bis es abgeschossen wird. Und dann (wenn man tatsächlich schon ein bestehendes Script verbessern will, sollte man mod_perl verwenden).
use Tschoe qw(Matti);
nicht unbeding FastCGI z.B. lädt halt den gesammten perl interpreter und das script nach und hält ihn im speicher... ohne das schöne apache interface...
Den Perl-Interpreter nur so zu laden ist so teuer das dieses wohl kein provider machen wird.
-
-
Hi Timo,
muchas gracias für Deine Antwort!
Mason ist eine möglichkeit perl direkt in html-seiten/templates einzubauen und viel, viel, mehr.
--- i will have a look...
54kb -- viel zu viel ! Ich hoffe du hast das "Kamel" Buch -
bau dir dein eigenes Modul/Module. oder einige Scripte.--- ich hab mich mal damit beschäftigt - ist ja prinzipiell ganz einfach. Wobei: wenn 54kb zuviel ist, ändert sich doch daran nichts, wenn ich -wie empfohlen- "use" verwende. Dann lädt doch der Interpreter am Start des Scripts sämtliche Routinen und das ist dann auch wieder alles, was zu dem Script gehört... Oder mach ich da einen Denkfehler?!
Alle Scripte die URL argumente mit reihen weisen ifelse auswerten sind seeehr suspekt.
--- ich versteh nicht? Du meinst damit, daß aufgrund von verschiedenen Argumenten verschiedene Aktionen ausgelöst werden. Das an sich ist doch nicht suspekt?! Also grundsätzlich lieber mehrere Scripte, jedes für einen Aufgabenbereich, und nicht ein Script für alles, wenn ich das richtig verstanden habe.Selbst mit einem 54kb Script kannst du sowas normaler weise nicht schocken.
--- gut zu wissen. Wobei ich den Vorteil der Module noch nicht ganz blicke. Ist übersichtlicher, aber das Laden der einzelnen Module dauert doch genauso lange, oder nicht?!
Ich habe glücklicherweise einen eigenen Server.
--- ich werde das auch bald haben, hoffe ich... :)
Oki, ich werde dann mal die Module auslagern und auf Deine Antwort warten... ;-)
Nochmal vielen Dank!
JOhnnY -
Hi Timo
54kb -- viel zu viel ! Ich hoffe du hast das "Kamel" Buch -
bau dir dein eigenes Modul/Module. oder einige Scripte. Alle Scripte die URL argumente mit reihen weisen ifelse auswerten sind seeehr suspekt.--- oki, ich hab mein Script auseinandergeplückt und verschiedene Module ausgelagert. Einige rufe ich mit "use" auf, weil sie bei jedem Aufruf verfügbar sein müssen - und andere mit "require" - so denke ich Speicherplatz und Rechenzeit zu sparen.
Übrig bleibt ein 2kb schlankes Hauptscript, das eben genau das macht, was Du als "seeehr suspekt" bezeichnest...:
.
.
.Newsletter-Anmeldung kommt von Webseite
Mail wird verschickt - Daten gespeichert
if($webform{optin} ne ""){require OptinFirst;}
User hat Link geklickt und wird in Newsletter-
Datenbank aufgenommen
if($action eq "+"){require OptinSecond;}
Newsletter-Abo-Anzeigen oder
wenn die eingegebene Frequenz keine Zahl ist...
if ($action eq "-" || $webform{freq} =~ /[^0-9]/ ){require AboShow;}
Speicherung der Newsletter-Abo-Änderungen
if ($webform{abochange} ne ""){require AboChange;}
Linkzähler
if ($action eq "!"){require LinkZaehler;}
.
.
.Mehr macht das Script nicht, als die URL-Daten auszuwerten und dann die entsprechend benötigten Module aufzurufen. Ich finde das auf jeden Fall schonmal weitaus übersichtlicher als vorher. Ist das nun dilletantisch programmiert? Also funktionieren tut es, soweit bin ich glücklich... ;))
Muchas Gracias!
JOhnnY -
Hi Timo,
Mason ist ein eigenes perl-modul und eigentlich dazu gedacht in die apache configuration mit eingebaut zu werden. Es geht aber auch ohne.
--- sieht auf den ersten Blick gut aus! Mein Provider hat es natürlich nicht installiert - wie geht es denn ohne?!
Ich bin vor etwa einem Jahr auf Mason gestossen und wiegere mich inzwischen unter einer anderen "Perl-Umgebung" zu arbeiten.
--- ja, das Konzept, Perl & HTML in einer Datei zu haben, scheint mir auch erhebliche Vereinfachungen zu bringen. So ganz habe ich das natürlich noch nicht geblickt, aber ich möchte das gerne lernen. Zuerst muß ich das Teil dann mal ins Laufen bringen... s.o.
54kb -- viel zu viel ! Ich hoffe du hast das "Kamel" Buch -
--- das was? Kamel-Buch? Bisher bin ich mit Self-HTML überall hingekommen, wo ich hinwollte... Problem ist nur: ich will immer noch weiter... <grins>
Auch wenn die Datei etwas grösser wird und du nicht die ganze Datei ausgeben willst sondern nur Zeile 107 wird es je nach deinen zugriffs Zahlen sinvoll eine DB einzusetzen.
--- äh, ja, das sei Dir mal so geglaubt, wobei meinem Verständnis nach Datenbanken mehr Ressourcen fressen als .txt-files? Irgendwann kommt der Umkehrpunkt, sagst Du...Wenn dir sich das nicht langfristig bietet... nimm PHP.
--- langfristig gesehen hoffe ich dann Programmierer einstellen zu können, die mir die Arbeit abnehmen. Ich programmier zwar gerne, aber eigentlich ist das gar nicht mein Job... :)
Zu PHP habe ich gelesen, es wäre gut, erst Perl zu können und dann PHP zu lernen. Da hab ich ja instinktiv die richtige Reihenfolge gewählt... :)
Danke Dir!
JOhnnY-
Hallo!
Zu PHP habe ich gelesen, es wäre gut, erst Perl zu können und dann PHP zu lernen. Da hab ich ja instinktiv die richtige Reihenfolge gewählt... :)
Wo hast Du das denn gelesen? Keine Frage, ist schon sehr gut wenn man vorher perl kann, wäre so dass man um mit Excel zu arbeiten besser erstmal Visual Basic lernen solte, sicher hat das Vorteile, dann kann man ganz schnell tolle Makros dahin zaubern, aber muß das wirklich sein?
Ich würde das bei PERL und PHP so ähnlich sehen. PHP ist _erheblich_ einfacher zu lernen und es funktioniert einfach! Wenn Dein Provider PHP unterstützt lädst Du einfach eine Flatfile mit<?
echo "hallo welt!";
?>hoch und Du mußt Dich nicht vorher wie bei Mason um zig PERL-Module... kümmern. Ich sehe bei der Web-Programmierung _keinen_ Vorteil für PERL. PHP wurde gerade _dafür_ entwickelt und wenn man auf ein paar Dinge achtet ist das auch genauso sicher/unsicher wie PERL. Manchmal habe ich das Gefühl das viele PERL-Fanatiker PHP schon nur aus dem Grund schlechtreden, weil fast "jeder DAU" mit erheblich weniger Aufwand als sie früher, schon recht viel erreichen kann. Sicher hat PERL viele Vorteil wie die vielen Moule in CPAN, nur eben müssen die auch installiert sein oder installiert werden können! PHP hat schon einiges an fertigen Funktionen dabei, was für den "Hausgebrauch" eines Web-Projektes IMHO durchaus komfortabel und vollständig ist. Bisher hatte ich 2 Anwendungen, die PHP zwar auch könnte, aber die durch bestimmte PERL-Module einfach viel besser in PERL umzusetzen sind, das ist einmal parsen von Excel und validieren von XML gegen DTDs.
Sonst ist PHP eigentlich auch wirklich mächtig, hat mit PEAR auch schon einige Module für einfach wiederverwertbaren Code, und mit SMARTY die beste "kompilierende" Template-Engine die ich kenne.
Außerdem finde ich das Session-Konzept in PHP hervorragend und einfach.OOP ist in PHP noch nicht so der Hit, aber in PERL IMHO auch nicht so viel besser - und daran wird auch unter Hochdruck gearbeitet.
Ich würde aus meiner Erfahrung sagen, das PHP erheblich einfacher und schneller zu lernen ist, und besser zugänglich und dokumentiert ist. PERL setze ich persönlich eigentlich nur für Shell-Scripte ein, da ist PERL erheblich besser geeignet als PHP.
Beide Sparachen haben Ihre Vorteile, mit PERL kann man so ziemlich _alles_ realsieren und das recht einfach (wenn an es kann!). Bei der Web-Integration sehe ich deutliche Vorteile für PHP, PHP ist gerade darauf optimiert. PERL ist mächtig aber wenn man zu viele große Module jedesmal komplett einbindet wird PERL recht langsam, daher weiß ich nicht ob Mason so gut geeignet ist. Für jemanden der PERL kann ist das sicher der beste Weg, aber für einen Neueinsteiger wage ich das mal zu bezweifeln. Man sieht schon bei der Einrichtung von PHP und Masen den großen Unterschied zwischen den Sparachen. In PERL ist halt alles möglich, aber dazu muss man erstmal ne ganze Menge Lernen bis man das auch wirklich einsetzen/ausnutzen kann, bei PHP legt man los und es funktioniert sofort und man macht sehr schnell Fortschritte.
Außerdem, ist ja alles schön und gut mit denm PERL-Modulen, nur bin ich mir sicher das man so ziemlich jedes Web-projekt komplett mit PHP umsetzen kann, also man braucht hier überhaupt keine speziellen Module, da die Sparache an sich für Web-Projekte mächtig genug ist.
Viele Grüße
Andreas
-
-