Wie funktioniert das mit Templates (Webframeworks, Sonstige Fragen zur Webprogrammierung mit Perl)

[thread]18555[/thread]

Wie funktioniert das mit Templates

Tags: perl5 Ähnliche Threads

Leser: 30

Articles: hide open all | hide show old branches

Teilbaum:
Wie funktioniert das mit Templates (8 Artikel) 2013-09-23 14:54

+9 replies
plinepa

2013-09-04 08:14

User since
2012-12-11
8 Artikel
BenutzerIn

Vielen Dank für Eure Beiträge!

Was ich bisher dazugelernt habe....
( Korrigiert mich bitte wenn ich da was falsches aufgeschnappt habe )

- CGI ist die "älteste" Variante bei welcher immer wieder ein neuer Perl-Prozess auf dem Server gestartet wird wenn die Seite geladen wird.

- mod_perl integriert Perl in den Apache und es ist um ein vielfaches schneller da nicht immer ein neuer Prozess gestartet werden muss.

Da mein Projekt "nur" eine kleine private Wetterstation darstellen soll werde ich erst mal CGI verwenden.

Es gibt praktisch keinen richtigen Load und keine konkurrierenden User, daher reicht meiner Meinung nach CGI erst mal aus.

Ich stelle also den Apache entsprechend ein und schon werden die .pl - Files im Verzeichnis entsprechend verarbeitet.

Bei PHP gibt es ja jetzt in den .php-Files die entsprechenden Sektionen in denen der Interpreter aktiv wird.
<?php echo '<p>Hallo Welt</p>'; ?>
Der Rest ist ja ganz normales HTML

Das ist doch aber bei Perl nicht so oder?

Oben steht ja der Shebang und der ganze Inhalt des .pl-Files wird ja vom Interpreter bearbeitet.

Daher bräuchte ich jetzt noch einen Schubs in die Richtung wie das mit den Templates funkt.
Das "Gerüst" mit <HEAD> & Konsorten kann doch bestimmt irgendwo ausgelagert werden.

Aber da sehe ich noch kein Land

Dankeschön :-)
plinepa

modedit Editiert von GwenDragon: Subthread
Last edited: 2013-09-04 11:12:02 +0200 (CEST)
- pq
  
  2013-09-04 10:37
  
  User since
  2003-08-04
  12208 Artikel
  Admin1
  
  das sind aber zwei verschiedene Schuhe.
  Es gibt als Technologie CGI, mod_perl und FastCGI. Da geht es darum, wie der Perl-Interprter gestartet wird.
  Da dürfte CGI erstmal ausreichen.
  
  Dann gibt es noch die Module, die man benutzt, um die Parameter auszulesen. Das geht von CGI.pm bis zu umfangreichen Webframeworks.
  CGI.pm ist einerseits eine minimale Lösung, schleppt aber andererseits viel Ballast in Form von Funktionen mit, die nicht mehr unbedingt empfohlen werden.
  Das Problem ist, geht man hin zu Frameworks, hat man die Qual der Wahl.
  Plack, CGI::Application, Web::Simple, Dancer, Mojolicious, Catalyst
  Wenn man mal mit einem Framework gearbeitet hat, will man manchen Komfort nicht mehr missen.
  
  Dazu kommen dann noch Templates (welche es übrigens bi PHP auch gibt, sie werden nur, wie bei Perl auch, nicht im üblichn 08/15 Skript eingesetzt).
  Auch hier gilt: es lohnt sich, sie einzusetzen, auch wenn es im ersten Moment nach etwas mehr Arbeit aussieht als das HTML direkt selbst auszugeben.
  Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. -- Damian Conway in "Perl Best Practices"
  lesen: Wie frage ich & perlintro brian's Leitfaden für jedes Perl-Problem
- +6 replies
- GwenDragon
  
  2013-09-04 11:00
  User since
  2005-01-17
  14536 Artikel
  Admin1
  Bei Perl kannst du mit HTML::Mason auch Perl-Code direkt in die HTML-Datei schreiben.
  Aber sinnvollerweise sollte Code und Inhalt getrennt werden.
  
  Ich arbeite mit HTML::Template::Compiled und benutze ein Perl-Programm als CGI-Handler beim Apache für die HTML-Dateien.
  
  Beispiel:
  
  Eine index.html:
  
  Code (html): (dl )
  
  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
  
  <html> <?INCLUDE HEAD1.html ?> <body> <h1><?= TITLE ?></h1> <p>Hier sind die aktuellen Wetterdaten von <?= NOW ?></p> <table> <caption>Wetterdaten für <?= MONTH ?>/<?= YEAR ?></caption> <?LOOP TABELLE1 ALIAS=ROW?> <tr> <?LOOP ROW ALIAS=DATA?> <td><?= DATA ?></td> <?/LOOP?> </tr> <?/LOOP?> </table> </body> </html>
  
  HEAD1.html:
  
  Code (html): (dl )
  
  1 2 3 4
  
  <head> <title>Wetteranzeige</title> <link rel="stylesheet" type="text/css" src="wd.css"> </head>
  
  Perlprogramm, welches die Datenein-/ausgabe verabeitet:
  
  Code (perl): (dl )
  
  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77
  
  #!/usr/bin/perl use strict; use warnings; use CGI; use LWP::UserAgent; use HTML::Template::Compiled; my $DOCUMENT_ROOT = $ENV{DOCUMENT_ROOT} || '.'; # für Fehlermeldumngen my $ERROR = ''; my $cgi = CGI->new; my @data; #### Wetterstation auslesen # my $lwp = LWP::UserAgent->new(); # hole aktuelle Tempertaturdaten von einer Wetterstation ab # Daten werden als Zeilen gesendet, in der Tab-sesparierte Daten vorliegen # Beispiel: # 1200 29.7 # 1300 31.2 # etc. # Über das HTTP-Protokoll abfragen my $result = $lwp->get('http://192.168.1.111/weather?date=today'); # falls die Abfrage fehlschlägt if ( not $result->is_success ) { $ERROR = 'Wetterstation nicht in Betrieb!' } # Abfrage war OK, Wetterstation hat was gesendet (hoffentlich die Daten ;) ) else { # Datenstrom einlesen my $rawstream = $result->decoded_content; # Datenstrom in einzelne Zeilen auftrennen und in Array speichern my @rawdata = split "\n", $rawstream; # Daten nun in eigene Arraystruktur (für Template später) speichern @data = map { [ ( split "\t" ) # Tabeseparierte Zeile aufsplitten und die Liste ] # in anonymes Array speichern } @rawdata; } ### Variablen für Datumsinhalte # my @MONATE = qw(- Jan Feb Mar Apr Mai Jun Jul Aug Sep Okt Nov Dez); my @localtime = localtime(); my $YEAR = $localtime[5] + 1900; my $MONTH = $MONATE[ $localtime[4] + 1 ]; my $NOW = "$localtime[3].$MONTH.$YEAR $localtime[2]:$localtime[1].$localtime[0]"; ### Erzeuge ein HHTML::Template::Compiled-Objekt # my $htc = HTML::Template::Compiled->new( filename => "$DOCUMENT_ROOT/index.html", tagstyle => [qw(-asp -comment +php -tt)], ); $htc->param( TITLE => 'Wetterstation 2', TABELLE1 => \@data, NOW => $NOW, MONTH => $MONTH, YEAR => $YEAR, ); print $cgi->header( -type => 'text/html' ), $htc->output; 1;
  
  Sendet dann folgendes beim Ablauf an den aufrufenden Browser:
  
  Code: (dl )
  
  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73
  
  Content-Type: text/html; charset=ISO-8859-1 <html> <head> <title>Wetteranzeige</title> <link rel="stylesheet" type="text/css" src="wd.css"> </head> <body> <h1>Wetterstation 2</h1> <p>Hier sind die aktuellen Wetterdaten von 4.Sep.2013 11:1.4</p> <table> <caption>Wetterdaten f├╝r Sep/2013</caption> <tr> <td>1700</td> <td>26</td> </tr> <tr> <td>1200</td> <td>29.3</td> </tr> <tr> <td>1800</td> <td>24.2</td> </tr> <tr> <td>1600</td> <td>27.3</td> </tr> <tr> <td>1500</td> <td>28.8</td> </tr> <tr> <td>1400</td> <td>31.2</td> </tr> <tr> <td>1300</td> <td>33.6</td> </tr> </table> </body> </html>
  
  Das geht alles natürlich noch strukturierter. Ich wollte es nur mal als Beispiel posten.
  Ich habs getestet, nicht mit einer Wetterstation sondern mit einem Programm auf einem lokalen Server, das mir nach Abruf Daten auspuckt.
  Last edited: 2013-09-04 11:02:09 +0200 (CEST)
  die Drachin, Gwendolyn
  
  Unterschiedliche Perl-Versionen auf Windows (fast wie perlbrew) • Meine Perl-Artikel
  - +5 replies
  - plinepa
    
    2013-09-04 11:37
    
    User since
    2012-12-11
    8 Artikel
    BenutzerIn
    
    Hallo GwenDragon!
    
    Das Beispiel hilft mir schon mal einen Riesenschritt weiter. DANKE!
    
    Doch wie sieht der Handler aus?
    Wie Du geschrieben hast passiert der Aufruf doch mittels eines CGI-Handlers im Apache:
    
    2013-09-04T09:00:03 GwenDragon
    
    Ich arbeite mit HTML::Template::Compiled und benutze ein Perl-Programm als CGI-Handler beim Apache für die HTML-Dateien.
    
    Doch wie schließt sich da der Kreis, das verstehe ich noch nicht?
    Sprich was steht in diesem Handlerskript?
    
    Das Perl-Handler-Skript ruft ja dann, so wie ich das sehe, das Perlskript auf welches das index.html zusammenschreinert.
    
    Der Baustein fehlt mir jetzt noch damit das in meinem Kopf rund wird.
    
    Vielen Dank
    plinepa
    - pq
      
      2013-09-04 12:03
      
      User since
      2003-08-04
      12208 Artikel
      Admin1
      
      GwenDragon hat doch das skript gepostet. In Zeile 64:
      filename => "$DOCUMENT_ROOT/index.html"
      
      Da passiert der Aufruf ans Template-System, welches die index.html lädt und mit den Parametern füllt und wieder zurückliefert (mit $htc->output).
      Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. -- Damian Conway in "Perl Best Practices"
      lesen: Wie frage ich & perlintro brian's Leitfaden für jedes Perl-Problem
    - +3 replies
    - GwenDragon
      
      2013-09-04 12:31
      
      User since
      2005-01-17
      14536 Artikel
      Admin1
      
      CGI-Handler in Apache in .htaccess:
      
      Code: (dl )
      
      1 2 3 4
      
      Action MyWetter /cgi-bin/wetterhandler.pl <FilesMatch "index.html$"> SetHandler MyWetter </FilesMatch>
      
      fängt alle index.html
      wetterhandler.pl ist das vorgestellte Perl-Programm.
      
      Ich weiß ja nicht, welche URLs und welche MIME-Types das programm bedeinen soll, welches die Templates erzeugt.
      
      Frag bitte einfach mal.
      Last edited: 2013-09-04 12:35:02 +0200 (CEST)
      die Drachin, Gwendolyn
      
      Unterschiedliche Perl-Versionen auf Windows (fast wie perlbrew) • Meine Perl-Artikel
      - +2 replies
      - plinepa
        
        2013-09-05 13:30
        
        User since
        2012-12-11
        8 Artikel
        BenutzerIn
        
        2013-09-04T10:31:55 GwenDragon
        CGI-Handler in Apache in .htaccess:
        
        Code: (dl )
        
        1 2 3 4
        
        Action MyWetter /cgi-bin/wetterhandler.pl <FilesMatch "index.html$"> SetHandler MyWetter </FilesMatch>
        
        OK, danke!
        Das war genau der Teil der mir zum Verständnis noch gefehlt hat.
        
        - Der User fordert index.html an
        - Apache fängt das ab und routet den Request weiter an wetterhandler.pl
        - In dem wird dann mit print $htc->output der fertig aufbereitete Inhalt ausgeliefert
        
        Gruß
        plinpea
        
        GwenDragon
        
        2013-09-05 13:39
        
        User since
        2005-01-17
        14536 Artikel
        Admin1
        
        Ja, du hast es korrekt verstanden. :)
        die Drachin, Gwendolyn
        
        Unterschiedliche Perl-Versionen auf Windows (fast wie perlbrew) • Meine Perl-Artikel
- martin.g
  
  2013-09-23 14:42
  
  User since
  2013-09-20
  40 Artikel
  BenutzerIn
  
  Nachtrag: Ich habe irgendwie die zahlreichen Antworten auf Deine Fragen nicht gesehen, sonst hätte ich jetzt nicht so viel Kram getextet. Für mich sah es aus, als hättest Du noch keine Antwort bekommen. Vergiss es einfach :-)
  
  Hallo plinepa,
  
  CGI ist generell mal nur eine Schnittstelle (das I steht für Interface) und hat nichts mit der Programmiersprache zu tun, mit der der Webserver kommuniziert. Apache kann mit Perl, PHP, Python, C und vielen anderen Programmiersprache CGI sprechen.
  Gemeint ist hier mit CGI ein Modul, das dir das Leben im Webumfeld ein gutes Stück leichter macht: http://search.cpan.org/~markstos/CGI.pm-3.63/lib/C...
  Du kannst den Header für ein HTML Dokument zu Fuß ausgeben (print "Content-type: text/html\n\n";) oder von CGI ausgeben lassen (print $cgi->header(-type => 'text/html');). Beim Header hast Du noch keinen ernsthaften Vorteil. Wenn es aber z.B. darum geht, GET/POST Parameter auszulesen, kommst Du an CGI.pm eigentlich nicht vorbei, weil es da so viele Besonderheiten bzgl. Query/POST, Encoding, Escaping usw. zu beachten gibt. In CGI liest Du den Parameter 'test' ganz einfach per my $parameter = $cgi->param('test');. Ohne CGI.pm musst dafür ausgiebig Query String parsen bzw. POST Content verarbeiten, sowie entscheiden, was von beiden Du nun tust usw. Zu Fuß also eine klare Empfehlung für CGI.pm
  Ich würde mich aber darauf beschränken, die Schnittstellen Funktionen von CGI.pm zu nutzen. Solche Sachen wie $cgi->h3('Meine Ueberschrift'); haben für mich im Regelfall nichts im Perl Code zu suchen.
  
  Wie Du schon festgestellt hast, sieht der Quelltext eine Perl Anwendung anders aus, als der einer PHP Anwendung. Vergleichbar werden sie erst, wenn Du Deine PHP Anwendung mit <?php beginnst und diesen PHP Block erst am Ende der Datei wieder schließt. Also keinen Inline Quelltext schreibst. Man könnte mit HERE Dokumenten usw. auch in Perl was vergleichbares machen, aber das ist kein guter Stil. HTML Quelltext gehört in Templates.
  
  Ein Fingerzeig für eine Template Engine ist das Template Toolkit. Sehr leistungsfähig und gut gewartet. Ich hatte schon ein paar andere in Gebrauch und bin letztlich dort hängen geblieben:
  http://search.cpan.org/~abw/Template-Toolkit-2.25/...
  
  Bzgl. Frameworks: Ich denke, dass es sinnvoll ist, erstmal zu Fuß mit CGI.pm die ersten Schritte zu machen. Frameworks sind leistungsfähig und haben viele Vorteile - brauchen aber auch viel Einarbeitung (einige mehr, andere weniger). Ich bin Catalyst Anhänger, aber frage zehn Leute und Du bekommst zehn Meinungen. Ich behaupte, dass Catalyst aktuell am verbreitetsten ist, aber es ist nicht für seinen Schnellstart bei Neulingen bekannt.
  
  Verbreitet sind momentan vier Möglichkeiten, sein Perl Skript unter Apache laufen zu lassen:
  - Als "normales" CGI: Wie Du richtig vermutest, wird es bei jedem Aufruf neu interpretiert und kompiliert, daher hat es immer einen gewissen Anlaufhuster. Bei einer einfachen privaten Webseite wirst Du davon aber nichts merken und auch keine Performance Problem bekommen.
  - mod_perl/mod_perl2: Damit habe ich beruflich längere Zeit gearbeitet. Es hat die gesamten Bibliotheken im Speicher und läuft bei häufigen Aufrufen schneller als ein normales CGI. Ich habe aber auch einige Schwierigkeiten bei mod_perl festgestellt. Erstens sind die Einstellungen im Apache dafür sehr komplex und es passiert schnell, dass ein mod_perl Skript den ganzen Webserver abschmieren lässt. Bei vielen Daten und ungünstiger Programmierung ist nämlich sehr schnell der Arbeitsspeicher voll. Außerdem lassen sich Skripte unter mod_perl bescheiden debuggen. Die Kopplung zwischen mod_perl und Apache ist extrem eng. Meines Wissens ist es nicht möglich, mehrere Anwendungen unter unterschiedlichen Benutzern auszuführen. Deshalb findest Du auch kaum Webhoster, die mod_perl Support anbieten.
  - mod_fastcgi: Verfolgt einen ähnlichen Ansatz wie mod_perl, die Kopplung zwischen Apache und Perl ist aber deutlich laxer. Man kann jede Seite unter einem anderen Benutzer laufen lassen und die Anwendungen können sich normalerweise nicht gegenseitig beeinflussen. Einmal komplierter Quelltext bleibt ebenfalls im Speicher und veringert die Ladezeit für alle zukünftigen Aufrufe. Der Nachteil ist, dass mod_fastcgi meines Wissens zwar kostenlos nutzbar ist, aber kein Opensource ist bzw. keiner gängigen Opensource Lizenz unterliegt. Deshalb muss man z.B. bei Debian die non-free Paketquellen aktivieren.
  - mod_fcgid: Ist (bzw. soll sein) ein binärkompatibler Nachbau von mod_fastcgi, der eine gängigen Opensource Lizenz unterliegt. Teilweise wurde noch von Inkompatibilitäten berichtet, aber ich habe noch keine festgestellt. Mittlerweile ist mod_fcgid mein bevorzugter Weg, Perl auf Apache laufen zu lassen. Auch mit Catalyst habe ich noch keine Probleme festgestellt.
  
  Die beiden letzten arbeiten standardmäßig ähnlich zum "normalen" CGI. Bzw. wirst Du vermutlich ohnehin eine der beiden Möglichkeiten nutzen ohne es zu wissen. Wenn Du die Vorteile des "Im-Speicher-haltens" nutzen willst, musst Du auch entsprechende Programme schreiben.
  
  Noch ein kurzes Wort zu Frameworks und diesen vier Varianten: Ich weiß nicht, wie es bei Dancer usw. ist, aber Catalyst arbeitet hervorragend mit mod_fcgid zusammen. Es ist deutlich spürbar, dass bei größeren Anwendungen der erste Start nach Webserver-Restart lange braucht (mehrere Sekunden). Das liegt an der umfangreichen Bibliothek, die kompliliert wird. Alle weiteren Aufrufe gehen dafür aber sehr flott.
  
  Viele Grüße
  Martin
  Last edited: 2013-09-23 14:54:22 +0200 (CEST)

View all threads created 2013-09-01 16:12.