nicht angemeldet
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.hms
Das 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);