nicht angemeldet
... oder Mason oder PHP oder Apache::ASP oder embperl?
Sup!
Ich habe gerade den Überblick über die vielen vielen Perl-ähnlichen Skripte-in-HTML-Einbettungssprachen verloren.
Alle sind angeblich grossartig, alle unterstützen die Ausführung (naja - PHP natürlich weniger) von Perl-Code, alle können irgendwie Sessions, alle haben Datenbank-Anbbindung.
Ich persönlich favorisiere gerade mod_perl & apache::session oder Mason oder (Igitt!) PHP.
Ich verstehe allerdings noch nicht ganz, was diese ganzen eingebauten Session-Management-Funktionen so grossartiges leisten...
Wo ist denn der grosse Unterschied zwischen mod_perl mit apache::session und apache::dbi und PHP?
Irgendwie sind das doch beides Syteme, die Sessions mittels eines persistenten Speichers (Datenbank) und persistenter Datenbankverbindungen verwalten, und bei denen ein in C geschriebener Compiler Skript-Befehle kompiliert und ausführt bzw. bei denen ggf. vorkompilierte Skriptstückchen ausgeführt werden.
Je mehr man sich mit dem Kram beschäftigt, desto verwirrender erscheint es.
Mason z.B.ist neben embperl und Apache::ASP ein weiterer Aufsatz für mod_perl, der alles besser und schöner machen soll. Alle drei ziehen eine objektorientierte Schicht ein, die irgendwelche Objekte bereitstellt, die das programmieren von "Web Applications" und Komponenten vereinfachen sollen. Blöderweise kann ich mir einfacher vorstellen, wie man selbst mit Sessions und einer Datenbank und einer Userverwaltung eine "stateful" Webapplication programmiert, als die Dokumentation zu diesen 3 "Technologien" zu verstehen.
Mason hat IMHO im Moment ähnliche Probleme wie PHP hatte, bevor sie die $HTTP_GET_VARS etc. eingeführt haben, damit man nicht so einfach Daten "injizieren" kann.
Also, was soll ich benutzen?
Kann man übrigens aus PHP heraus ein Perl-Skript aufrufen, und dessen Ausgabe als Rückgabewert in Variablen einlesen?
Gruesse,
Bio
-
use Mosche;
Mason z.B.ist neben embperl und Apache::ASP ein weiterer Aufsatz für mod_perl, der alles besser und schöner machen soll. Alle drei ziehen eine objektorientierte Schicht ein, die irgendwelche Objekte bereitstellt, die das programmieren von "Web Applications" und Komponenten vereinfachen sollen. Blöderweise kann ich mir einfacher vorstellen, wie man selbst mit Sessions und einer Datenbank und einer Userverwaltung eine "stateful" Webapplication programmiert, als die Dokumentation zu diesen 3 "Technologien" zu verstehen.
Ich benutze HTML::Mason jetzt über ein Jahr lang, und es hat sich eigentlich ganz gut gemacht. Das einzige, was wirklich nervt, ist die "fehlerhafte" Zeilenangabe bei Fehlermeldungen (da die Zeilennummer des erzeugten Perl-Scripts genommen wird und nicht die Zeilennummer meines HTML::Mason Scripts).
Ansonsten kann man wirklich gut damit arbeiten.
Was halt passiert, wenn du Mason benutzt, ist deine gesamte Arbeitsweise umzustellen. Du verlierst die Perl-Beschränkungen, was die CGI-Umgebung angeht (wie diese wirklich einschränken, merkt man erst, wenn sie wirklich weg sind), gewinnst PHP ähnliche Vorteile, schreibst aber noch Perl (und kannst damit angeben :-)), ...
Mason hat IMHO im Moment ähnliche Probleme wie PHP hatte, bevor sie die $HTTP_GET_VARS etc. eingeführt haben, damit man nicht so einfach Daten "injizieren" kann.
Könntest du das nochmal erläutern?
Also, was soll ich benutzen?
Ich kenne die anderen nicht so gut, ich kann dir Mason nur wärmstens empfehlen. Das Problem dabei ist, dass bisher nur wenige Provider Mason anbieten - es ist einfach noch zu wenig verbreitet.
use Tschoe qw(Matti);
-
Sup!
Das mit dem Provider ist kein Problem - Ich provide mich selbst, auf meinem Rechner zuhause ;-)
Da brauche ich gar nicht XWolf zu belabern, Mason zu installieren (oder es selbst machen ;-)).Ehm - mir schien, als ob bei Mason die einzelnen Komponenten Variablen als "Aufrufparameter" erwarten, und als ob Mason nicht merkt, ob eine Variable z.B. per GET oder POST gesetzt worden ist. Vielleicht habe ich das auch falsch verstanden...
Hast Du vielleicht ein bisschen Quellcode für ein wenig Mason, als Beispiel, für das "getting started"? Vielleicht kannst Du noch ein paar Vorteile aufführen - kann ich wirklich jedes abgefahrene Perlmodul benutzen? Wo sind die Beschränkungen, wo die Vorteile? Wie ist das mit dem Cache? Irgendwo habe ich gelesen, man müsse manchmal irgendwelche Cache-Dateien per Hand aufräumen http://www.masonhq.com/docs/manual/Devel.html#data_caching. Ist Dir das schon mal passiert?
Und wie schnell läuft Mason so?
Ehmm... das ist Deine Chance, mich zum Mason-Jünger zu machen ;-)
Gruesse,
Bio
-
use Mosche;
Ehm - mir schien, als ob bei Mason die einzelnen Komponenten Variablen als "Aufrufparameter" erwarten, und als ob Mason nicht merkt, ob eine Variable z.B. per GET oder POST gesetzt worden ist. Vielleicht habe ich das auch falsch verstanden...
Du bemerkst GET/POST Unterschiede wirklich nicht, da alle Parameter in einen Hash namens %ARGS einfliessen (bzw. in einem speziellen Auschnitt mit Variablen belegt werden können (s.u.)).
Hast Du vielleicht ein bisschen Quellcode für ein wenig Mason, als Beispiel, für das "getting started"?
OK, ich probiers mal:
<%doc>
Hier steht Doku. (mehrzeilige Kommentare)
Mit diesem Tool kann man den Seitenhintergrund
serverseitig setzen
sehr wichtig !im %args Abschnitt können Variablen aufgeführt werden
diese bekommen Werte aus den gleichnamigen Parametern
das sind skalare Daten, oder, wenn mehrere Werte für
ein Value vergeben werden (checkbox, ...), anonyme Arrays
</%doc>
<%args>
$background_color => '#000000' # background-color: default ist #000000
</%args>
<%perl>
# das ist ein mehrzeiliger Perl-Abschnitt
if ($ARGS{'font_color'} eq $background_color) {
# die zweite Methode, Parameter abzufragen
# jetzt irgendwas mit den Farben machen
}
</%perl>
% # einzeiliger Perl-Abschnitt
<html>
<head>
<title><% $ARGS{'title'} || 'Test' %></title>
<%doc>
in <% ... %> Abschnitten wird Perl Ausgeführt, Rückgabewerte
werden ausgedruckt
</%doc>% # jetzt der Rest der Seite
Vielleicht kannst Du noch ein paar Vorteile aufführen - kann ich wirklich jedes abgefahrene Perlmodul benutzen?
IMHO ja. Ich benutze meistens DBI und eigene Module, das funktioniert reibungslos. Warum auch nicht? Mason übersetzt seine eigene 'Sprache' ja in Perl-Anweisungen, die dann ausgeführt werden.
Wo sind die Beschränkungen, wo die Vorteile?
Vorteile sind eigentlich recht klar. PHP ähnliche HTML Ausgabe, ein gutes Komponenten Konzept (s.u.), aber Perl (mit CPAN).
Du schreibst im Grund HTML, aber kannst darin in entsprechenden Abschnitten Perl einbetten. Der Witz sind die Komponenten. Beispiel: Die Datei oben heisst hintergrund.hms (hms hat sich mein Bruder ausgedacht, um Mason Komponenten zu kennzeichen) und liegt in /blah/.
Dann ruft Mason folgende Dateien auf:
/autohandler
/blah/autohandler
/blah/hintergrund.hmsDas heisst, du kannst in /autohandler bereits ein rudimentäres Design zusammenflechten (natürlich konfigurierbar), das in /blah/autohandler verfeinern. Die eigentliche Anwendung kommt erst danach und hat nichts mehr mit dem Design zu tun. Das heisst vollständige Trennung von Inhalt und Design. Das ist meines Erachtens der größte Vorteil. Die HP, auf der ich Mason einsetze, hat in den eigentlichen Dateien nur Text, das Design wird komplett von autohandlern zusammengesetzt. Von aussen ist das aber nicht sichtbar (deswegen keine URL).
Wie ist das mit dem Cache? Irgendwo habe ich gelesen, man müsse manchmal irgendwelche Cache-Dateien per Hand aufräumen http://www.masonhq.com/docs/manual/Devel.html#data_caching. Ist Dir das schon mal passiert?
Das kann mal passieren. Mason macht das intern so:
beim ersten Aufruf einer Mason-Komponente wird die Komponente interpretiert und in Perl umgewandelt. Diese Perl-Stückerl wandern in den Cache. Wenn die nächste Anfrage für diese Komponente kommt, wird sie aus dem Cache beantwortet. Um eine übersetzte Komponente als 'alt' zu identifizieren, benutzt Mason irgendwelche Timestamps. Wenn du die Datei zwischendurch änderst, sollt Mason die Komponente neu übersetzen. Das geht manchmal (recht selten eigentlich) schief. Dann musst du diese Dateien per Hand löschen. Das passiert aber nur im Änderungsprozeß (wie gesagt: selten), nicht in der Produktion.Und wie schnell läuft Mason so?
Das kann ich dir ehrlich gesagt nicht so beantworten, da die Pages, die ich mit Mason mache, auf einem Server laufen, der fast nur damit zu tun hat und trotzdem recht gut ausgerüstet ist. Beim ersten Aufruf der Komponenten kann es ein bißchen länger dauern (so ne sec.), bei den nächsten Aufrufen ist die Zeit wahrscheinlich äquivalent den Zeiten eines CGI-Scriptes.
Das Problem bei Mason ist vor allem, dass es wenig Anwender gibt, und (wie Perl) eine recht grosse "Vielfaltigkeit" aufweist. Du wirst dich durchbeissen müssen.
Im Gegensatz zu manch anderen perldocs ist
perldoc HTML::Mason::Devel
aber wirklich verständlich. Ich habs hauptsächlich damit gelernt.Fazit: Mason ist wirklich mal eine Blick wert, den wahren Wert wirt man allerdings erst auf den 4. Blick erkennen, dafür ist der riesengroß.
use Tschoe qw(Matti);
-
Sup!
Kann ich denn rausfinden, ob die request-method get oder post war?
Kann ich cookies auslesen oder setzen?Können sub-komponenten auf die aufrufparameter der top-level-komponente zugreifen? Wohl nicht, oder? Von wegen Kapselung und bla...?
Gruesse
Bio
-
Sup!
Kann ich denn rausfinden, ob die request-method get oder post war?
Wie üblich: $ENV{'REQUEST_METHOD'}.
Kann ich cookies auslesen oder setzen?
Ja. Siehe hierzu HTML::Mason::Devel, Sektion `SENDING HTTP HEADERS'. Da ist ein entsprechendes Beispiel.
Können sub-komponenten auf die aufrufparameter der top-level-komponente zugreifen? Wohl nicht, oder? Von wegen Kapselung und bla...?
Können sie nicht. Man kann aber alle Parameter (ggf. modifizierte) durch den Hash %ARGS weitergeben:
$m->comp('/subcomp', test => blah, blub => blab, %ARGS);
Die andere Komponente wird dann aufgerufen und erhält den (zusammengefassten) übergebenen Hash als %ARGS.
use Mosche;
-
-
Hast Du vielleicht ein bisschen Quellcode für ein wenig Mason, als Beispiel, für das "getting started"?
Lieber Bio,
eine etwa 30 Seiten lange EInführung zum Thema Mason findest Du in "CGI-Anwendungen mit Perl" von Addison-Wesley. (mit 50 Euro wie vieles auf diesem Gebiet unverschämt teuer).
Viele Grüße
Mathias Bigge
-
Sup!
Tja, also fuer die 30 Seiten kauf' ich mir das Buch nicht - 50Euro waeren ja kein Problem oder so, aber fuer die 30 Seiten...
Aber danke fuer den Tipp ;-)Gruesse,
Bio
-
-
-
-
-
hi!
Ich persönlich favorisiere gerade mod_perl & apache::session oder
Mason oder (Igitt!) PHP.Zu Masen kann ich noch einen Link anbieten:
http://www.heise.de/ix/artikel/2002/02/128/Da findest du auch Beispiele und weitere Links.
bye, Frank!