cvsroot/docs/papp.sdf

!init OPT_STYLE="paper"

!define DOC_NAME        "PApp - Perl-Anwendungen für die Zukunft des WWW"
!define DOC_AUTHOR      "Marc Lehmann <pcg@goof.com>"
!build_title

H1: PApp - Wie beschreibt man ein Chamäleon?

PApp ist schwer zu beschreiben, da es sich nicht auf ein spezielles
Problem spezialisiert sondern möglichst eine offene Universallösung sein
will. Unter anderem ist PApp:

- ein Embedded-Perl-Dialekt. Es gibt verschiedene Formen: Ein "literal
programming style", der nicht XML-konform ist sondern beliebige Daten
ausgeben kann und viele Möglichkeiten des Einbettens von Perl in
XML. Schliesslich gibt es noch den Standard-XML-Dialekt, der eine Mischung
aus beidem darstellt.

- Perl-Module, die das Arbeiten in einer CGI-artigen Umgebung
erlauben. Die Umgebung hält sich mehr an Apache, ist jedoch unabhängig
davon, ob die PApp-Anwendung in einer CGI-Umgebung, unter mod_perl oder
unter CGI::SpeedyCGI ausgeführt wird.

- Eine Bibliothek (aus vielen Modulen), die das Arbeiten mit HTML, XML,
SQL und anderen, häufig benutzten Umständlichkeiten vereinfacht.

- Eine grosse "State-Maschine", die technisch getrennte Programmteile
(z.B. CGI) logisch zu {{einer}} Applikation zusammenfasst.

- Ein XSLT-Stylesheet-Prozessor. Damit kann man Layout und Inhalt
voneinander trennen. Oder auch Ausgabeformat (PDF/HTML/XML etc.) vom
Layout. Oder vom Inhalt...

H2: Warum PApp geschrieben wurde

Grosse und kleine Applikationen für das WWW zu erstellen ist sehr
arbeitsaufwendig. Session-Variablen kennt Perl nicht, Session- und
Usertracking natürlich auch nicht. Es gibt sehr gute Module, die einem
einen Teil der Arbeit abnehmen, aber es ist immer sehr aufwendig und
umständlich. Dies führt zu unübersichtlichen Programmen, die noch dazu
auf viele Dateien aufgeteilt sind, die nicht unbedingt der inneren Logik
des Programmes entsprechen. Auch Sicherheitsfehler (wie das Übergeben
von sicherheitsrelevanten Daten über {{hidden-fields}} moder ähnliches)
passieren schnell, schliesslich muss man sich bei jeder Seite überlegen,
wie man seine Daten weiterreicht.

Datenbankabfragen, das Einbauen des Layouts sind sehr
umständlich. Internationalisierung existiert praktisch nicht.

PApp vereinfacht alle diese Probleme, indem es sie weitestgehend
automatisiert.

H1: Grundlegende PApp-Features oder "Nie wieder CGI"

Zunächst möchte ich einige der vielen Features von PApp vorstellen
(natürlich die wichtigsten ;). Wem das zu langweilig ist und erstmal
eine richtige PApp-Applikation sehen will, sollte zum nächsten Abschnitt
gehen, "Eine einfache Anwendung mit PApp".

H2: Applikationen statt Einzelseitenverwaltungsmonstren

Bei CGI oder anderen Schnittstellen ist die Sicht auf die Anwendung
protokollbedingt seitenbasiert - jede "logische" Seite ist eine Datei
oder eine Fallunterscheidung innerhalb der Datei - gemeinsame Komponenten
müssen in Bibliotheken (oder auch nur Include-Dateien; ist im Prinzip
das gleiche) abgelegt werden die auf jeder Seite erneut geladen,
konfigurietr und eingebaut werden müssen. Perl-Programme funktionieren
jedoch anders, da gibt es keine Zustände, die beim anklicken wechseln,
sondern ein lineares Programm. Dies läßt sich zwar auch mit PApp nicht
verwirklichen, aber es tut sein Bestes, diese Einschränkungen wegzuheben,
indem es ganze Anwendungen bearbeitet: Ob mehrere Seiten in einer Datei
oder eine Seite auf mehrere Dateien verteilt wird ist in PApp egal.

H2: development/maintainance: Aktivposten statt Bremsklötzen

H3: Entwicklungshilfe

Programme - auch solche, die mit PApp geschrieben werden - müssen erst
entwickelt werden. Dabei werden Fehler gemacht. Da bei PApp sehr viele
Komponenten zusammenwirken können die Fehler entsprechend komplex
sein. Eine gute Unterstützung bei der Fehlersuche ist also wichtig.

Dies fängt damit an, dass die Zeilennummern des Quelltextes auch nach
der Kompilierung von Perl/XML zu reinem Perl oder z.B. in ein XSLT
erhalten bleiben. Sollte ein Fehler auftreten, so hat man sofort Zugriff
auf die Qeulldateien, einen kompletten Backtrace und natürlich die
State-Daten. Das Exception-System von PApp ist einfach zu benutzen (C<die>
genügt, will man es schöner haben benutzt man C<fancydie> ;) und
erweiterbar.

Im Betrieb will man natürlich keine ausführlichen Fehlermeldungen,
komplett mit Passwort der Datenbank usf... Deshalb protokolliert PApp
alle Fehler in eine SQL-Datenbank zusammen mit der State-ID, so dass
nur die Fehlerkategorie (plus ein nettes Textfeld, in dem der Benutzer
zusätzliche Informationen eingeben kann). Solange die Seite nur
wiederholbare Aktionen enthält, kann der Entwickler den Fehler jederzeit
reproduzieren.

H3: Datenbanken

Wie soll man ohne auskommen? Natürlich garnicht. In Perl gibt es ein ganz
wunderbares System (DBI!) um mehr-oder-weniger genormt auf SQL-Datenbanken
zugreifen zu können. Jetzt ist "nacktes" DBI recht umständlich,
zumindest für mich, für den vier Aufrufe pro SQL-Befehl entschieden zu
viel sind. Vor allem, wenn man diese über das Programm verstreuen muss.

In PApp erledigt man die meisten Aufgaben mit der C<sql_exec>-Funktion
(den Rest erledigt man mit C<sql_fetch/fetchall/exists/insertid>). Der
folgende Aufruf ersetzt C<prepare>, C<bind_params>, C<execute> und
C<bind_columns>:

!block perl
 my $st = sql_exec \my($p, $w),
                   "select purzel, wurzel from table
                    where name like ?",
                   $S{search};
 
 while ($st->fetch) {
    echo "$p, $w\n";
 }
!endblock

Der besondere Clou: Die SQL-Statements werden gecached, d.h. im
Allgemeinen nur ein einziges mal C<prepare>d. Bei Datenbanken, die einiges
an Aufwand in diesem Schritt investieren (Stichwort Query-Optimizer)
ist das ein grosses Plus. Sogar bei Datenbanken, die dies nicht tun
(z.B. MySQL) steigt die Geschwindigkeit merklich. Zudem sind das
C<prepare> und das C<execute> in normalen Programmen getrennt voneinander
(die Befehle stehen weit auseinander).

Bei Datenbanken, die eine Art "insertid" unterstützen (zum Glück fast
alle), kann man diese nach einem C<INSERT> gleich mit abfragen:

!block perl
 my $id = sql_insertid
             sql_exec "insert into tiere (name) values (?)",
                      "hase";
!endblock

Den Database-Handle habe ich übrigens nicht vergessen: Wenn ich
keinen angebe, wird ein Default-Handle benutzt. Geschickterweise wird
dieser von PApp selbst gesetzt, so dass man sich im Normalfall noch
nicht einmal um die Datenbankverbindung kümmern muss (weil diese auf
dem Produktionssystem meistens andere Passwörter hat als auf dem
Entwicklungssystem stellt man diese geschickterweise bei der Konfiguration
der Applikation ein).

<<admin.png>>

H2: Trennung von Quelltext und Sprache

H3: XML

XML wird in mehreren Teilen von PApp unterstützt bzw. gefordert: Der
Standard-Dialekt von PApp ist in XML geschrieben, d.h. um "normale"
PApp-Applikationen zu schreiben muss man sich XML bedienen. Die Ausgabe
von PApp (meistens Text) ist beliebig, sofern man keine Stylesheets
benutzt. Tut man das, muss die Ausgabe natürlich in XML-Syntax sein. Und
last-not-least gibt es ein PApp-Modul, mit dem man beliebige XML-Fragmente
mit eingebettetem Perl-Quelltext bearbeiten/ausführen/anzeigen kann.

Die Entscheidung, XML so zentral einzusetzen, fiel mir nicht
leicht: Meiner Meinung nach ist XML wunderbar dafür geeignet,
Daten innerhalb von Programmen zu verarbeiten und vor allem
auszutauschen. Toll ist, dass Menschen XML notfalls lesen und auch
schreiben können. Ansonsten ist doch die Mächtigkeit von SGML (oder
etwas anderem) vorzuziehen.

XML jedoch hat bestechende Vorteile: HTML ist eine XML-Applikation (und
HTML ist wichtig ;); es existiert eine breite Unterstützung für XML;
es gibt bestehende Standards für Stylesheets, Layout, Metadaten und
mehr. Schliesslich ist XML auch noch sehr schnell. Nun ja.

Das hat mich trotzdem nicht davon abgehalten, etwas oben
draufzusetzen: Fast alle Dokumente können in einem "Meta-Format" mit
eingebettetem Perl-Quelltext geschrieben werden. Die Standard-Syntax
dafür bedient sich vier sog. "Modus-Umschalter", die jeweils vom
"Verbatim" in den "Perl"-Modus bzw. zurück schalten:

!block verbatim
 <:          schalte von HTML in Perl um
 <?          wie <:, füge jedoch das Ergebnis in die Ausgabe ein

 :>          schalte in den HTML-Modus
 ?>          schalte in den interpolierten HMTL-Modus
!endblock

Diese Modus-Umschalter habe ich in den Beispielen schon verwendet, z.B.
kann man eine HTML-Seite so schreiben:

!block perl
 <h1>Ein bisschen HTML</h1>
 <: echo "mit eingebautem perl" :>
 <: print "so gehts auch, ist aber unendlich wenig langsamer ;)" :>
 <?"So gehts am schnellsten":>
 <:for my $text (qw(Noch eine komische Methode)) {
    ?>$text&#160;<:
 }:>
!endblock

Die Modus-Umschalter verhalten sich dabei wie eine Statement-Grenze in Perl (also C<;>).

H3: I18n

I18n steht kurz für Internationalisierung: Das englische Wort
{{Internationalization}} hat 18 Buchstaben zwischen dem 'I' und dem
'n', und da das Wort für den Durchschnittsamerikaner viel zu lang und
kompliziert ist, hat man diese 18 Buchstaben einfach durch "18" ersetzt.

In Kontext von PApp bedeutet dies, dass beinahe überall Textmeldungen
übersetzt werden können (wer das C<gettext>-Paket kennt, mit dem
üblicherweise C-Programme internationalisiert werden, wird sich fast
sofort Zuhause fühlen). Hier ist ein Beispiel:

!block verbatim
 <h1>__"Contents"</h1>
 <:for (1..10) {:>
    <?slink sprintf(__"Chapter %d", $i++),
            "view_chapter", chapterid => $i:>
 <:}:>
!endblock

Wie man sieht, kann man C<__"text"> sowohl im
HTML/XML/wasauchimmer-Quelltext benutzen, als auch auf Perl-Ebene
aufrufen. Die C<__>-Funktion erledigt dabei zwei Aufgaben: Zunächst werden damit
Textkonstanten zum übersetzen {{markiert}}. Zur Laufzeit wird dann in der Übersetzungstabelle nachgesehen und
der (evt.) übersetzte String zurückgeliefert.

Wenn man Daten z.B. aus einer Datenbank in eine Variable holt, darf man diese natürlich {{nicht}} markieren, da sie ja nur zur Laufzeit einen String {{enthält}}, selbst
aber keine Textkonstante ist. In solchen Fällen verwendet man C<gettext>:

!block perl
 my $st = sql_exec \my($id, $name), "select id, name from table";

 while ($st->fetch) {
    echo "<li>", gettext$name, "</li><br/>";
 }
!endblock

In welche Sprache jeweils übersetzt wird, entscheidet bei HTTP die
Einstellung des Browsers, wobei man zweckmässigerweise ein Menü
anbietet, in dem der Benutzer dies überschreiben kann:

!block perl
 <?slink "I want English", SURL_SET_LANG => "en":>
 <?slink "Deutsch willich!", SURL_SET_LANG => "de":>
!endblock

Auch die Spracheinstellung ist eine Preferences-Variable. Im Gegensatz
zum C<gettext>-Paket müssen die Quelltext nicht alle in einer Sprache
sein. Bei C<gettext> ist das auch weniegr ein Problem, da der Quellcode
eines Programms meistens in einer (natürlichen) Sprache geschrieben
wurde, in PApp kann man aber Seiten dynamisch einfügen oder Datenbanken
übersetzen. Da diese meist nicht vom selben Team geschrieben werden, ist
es nützlich, dort unterschiedliche Sprachen verwenden zu können.

<<poedit1.png>>
<<poedit2.png>>

H3: Unicode / Zeichensatzunabhängigkeit

Intern unterstützt PApp genau zwei Datentypen (genau wie Perl
selbst): {{Binärdaten}} und {{Text}}.  Binärdaten verwendet man
üblicherweise für Bilder, Datei-Downloads und ähnliches.  Diese Daten
werden von PApp nicht angerührt.

Ganz anders Text: Perl arbeitet intern mit Unicode, das z.Zt. entweder in
ISO-8859-1 oder UTF-8 gespeichert wird. Dieser interne Zeichensatz ist
völlig unabhängig von der Ausgabe, d.h. der Text wird bei der Ausgabe
automatisch in den gewünschten Zeichensatz kodiert (das geschieht wieder
Browser/Benutzer/Programmabhängig wobei von den gebräuchlichen Browsern
nur Netscape und Lynx die entsprechenden Header liefern). Umgekehrt werden
Formulardaten u.ä. automatisch in Unicode gewandelt, d.h. in C<%P> steht
Unicode auch wenn der Browser ein Formular in ISO-2022-JP zurückgeschickt
hat.

Ein JPEG-Bild kann man z.B. so ausgeben:

!block perl
 content_type "image/jpeg", undef;
 $gd->jpeg(80);
!endblock

Während man eine japanische Benutzerin vielleicht mit ISO-2022-JP
zufriedenstellen kann:

!block perl
 content_type "text/html", "iso-2022-jp";
 echo __"Hoffentlich war der Übersetzer fleissig";
!endblock

H2: Trennung von Daten und Layout/Protokoll

Sprache und Quelltext trennt PApp ja schon. Jetzt muss man noch das Layout
vom eigentliche Programm bzw. das Protokoll von den eigentlichen Daten
trennen.

Mit XSLT-Stylesheets geht das. Und mehr: "Browser XYZ hat ein Problem? Ich
fix' es im Stylesheet und vergesse es dann einfach." (z.B. sollte man
leere HTML-Tabellenzellen für Netscape lieber mit einem C<&nbsp;>
füllen).  "Es soll WML (oder CHTML) sein? Ich weiss zwar nicht, wozu
das ganze WML-Zeugs sinnvoll sein soll, aber dann mache ich halt' ein
Stylesheet dafür." Und eine der wichtigsten Anwendungen:  "Wir brauchen
eine Version zum drucken. Dafür wandeln wir unser XML-Dokument in XSL" (und dann
nach Latex, PDF...).

Das bedeutet, dass man - Planung natürlich vorausgesetzt - einen hohen
Grad an Protokollunabhängigkeit erreichen kann, ohne den Quelltext zu
sehr mit Layout-Entscheidungen o.ä. belasten zu müssen.

Leider gibt es noch keine Web-Designer, die XSLT statt HTML/CSS liefern,
aber (meine) Vision des Webs der Zukunft sieht so aus: Der Server liefert
XML zusammen mit einem XSLT (vom Designer), welches XSL erzeugt. Dieses
wird dann angezeigt/gedruckt etc.a.. Metadaten (mit dem etwas besseren
Nachfolger von RDF) gestatten dann Fragen wie: "Wer hat dieses Dokument
geschrieben?", "Wozu dient es?" aber auch: "Wieso ist das Ding so bunt?".

H2: Trennung von Funktionalität und Ausführungsumgebung

Platform-Unabhängigkeit: ein toller Begriff. Was bedeutet er? Nicht
viel. Bei PApp bedeutet es, dass auf Unix-Abhängigkeiten möglichst
verzichtet wurde und sich PApp nicht an einen bestimmten Server
(z.B. Apache) bindet. In der Praxis kann man als Platform mod_perl
oder CGI verwenden und für Windoze schere ich mich einen Dreck.  Aber
auch andere Umgebungen wie Text-Interfaces sind denkbar: Da PApp der
Applikation immer eine gleichbleibende Umgebung anbietet, muss man
lediglich ein Schnitstellenmodul schreiben.

H2: Persistente Variablen für Sessions und User

PApp kümmert sich automatisch um persistente Variablen. So kann man
automatisch Variablen erzeugen, die über eine gesamte Sitzung (die mit
dem Aufruf der ersten URL beginnt und dann einen Baum bildet) persistent
sind. Das geht so einfach, dass man spezielle Hilfsmittel braucht, um
nicht an jeder Stelle der Sitzung Zugriff auf beinahe alles zu besitzen.

Persistente Variablen gibt es in verschiedenen Geschmäckern. Es gibt:

- Session-Variablen (sogenannte {{state keys}}), die über eine gesamte
Sitzung erhalten bleiben. Diese werden im Hash C<%S> gespeichert. Man kann
beliebige Werte darin ablegen (solange C<Storable> diese serialisieren
kann). Meistens gescheiht dies durch Anklicken eines Links, weniger
häufig direkt.

- Benutzerabhängige Variablen (die auch über Sitzungsgrenzen hinaus
erhalten bleiben und deshalb {{preferences items}}, Voreinstellungen,
heissen). Auch diese befinden sich in C<%S>, von wo sie automatisch in die
Benutzerdatenbank wandern bzw, von dort gelesen werden.

- Lokale Variablen ({{local keys}}) zu nur innerhalb einer Seite oder
einer Gruppe von Seiten Bedeutung haben. Diese befinden sich ebenfalls in
C<%S> und werden automatisch daraus entfernt.

- oder beliebige Kombinationen davon.

Ein Beispiel für eine Sitzungsvariable ist die Information, ob der
Benutzer sich schon angemeldet/eingeloggt hat oder ob er bestimmte
Zugriffsrechte besitzt.  Eine benutzerabhängige Variable ist z.B.die
Sprache, die der Benutzer zuletzt ausgewählt hat (global) oder die
Anzahl der Tabellenzeilen, die der Benutzer gerne auf einer bestimmten
Seite angezeigt haben möchte. Eine lokale Variable ist z.B. ein
Datenbank-Objekt, das über mehrere Seiten (z.B. einer Transaktion)
gebraucht wird und danach seine Gültigkeit verliert.

Dadurch ergeben sich mehr Möglichkeiten, als man erwarten
würde: Unabhängige Komponenten (z.B. Werbebanner oder Foren) sind auf
normale Weise nur sehr schwer zu programmieren, da sie immer Hilfe vom
"Hauptprogramm" erfordern wenn es um die Parameterübergabe geht. In PApp
benutzt man einfach persistente Variablen.

Ein Beispiel für eine etwas ungewöhnlichere Komponente ist die
{{editform}}-Bibliothek. Mit ihr kann man HTML-Formulare erstellen, die
sich direkt an eine bestimmte Variable binden:

!block perl
 ef_begin;
 ef_string \$S{search};
 ef_end;
!endblock

Dieses Beispiel stammt von einer Seite, die Objekte aus einer Datenabnk
anzeigt und sich dabei auf solche beschränkt, die ein Suchwort
enthalten. Das Formular bindet die State-Variable C<search> an ein
HTML-Textfeld. Bei der Ausgabe wird der aktuelle Wert von C<$S{search}>
benutzt. Ändert der Benutzer den Text und schickt das Formular ab wird
die Seite neu aufgebaut - mit einem anderen Wert in C<$S{search}>. Da
editform beliebige Perl-Referenzen akzeptiert und man in PApp auch
Referenzen auf Dateien, SQL-Spalten etc... erzeugen kann werden viele
Formulare zum Kinderspiel.

Zusätzlich zu den Sitzungsvariablen gibt es noch sogenannte
{{Argumente}}, die nur eine Seite lang "persistent" sind, d.h. bei einem
Link auf eine andere Seite übergeben werden:

!block perl
 echo slink "Klicken Sie hier", -argument1 => "wert1", var2 => "wert2";
!endblock

Wenn man diesem Link folgt, steht der "wert1" im Hash C<%A> bzw. "wert2"
im Hash C<%S>:

!block perl
 printf "Das Argument argument1 ist %s, die State-Variable var2 ist %s",
        $A{argument1}, $S{var2};
!endblock

Werte, die von "Aussen" (z.B. GET-Request in CGI) kommen, stehen, um die
Verwirrung komplett zu machen, in C<%P>. Als Faustregel gilt: was in C<%S>
und C<%A> steht ist sicher (bzw. man hat es selbst dorthin gepackt), was
in C<%P> steht ist unsicher und muss erst gefiltert/geprüft werden.

H2: Sicherheit

In vielen CGI-Programmen (aber nicht nur dort) wird der Fehler
begangen, sensitive Daten in {{hidden}}-Feldern in einem Formular zu
"verstecken" oder sie in die URL zu kodieren um die Parameterübergabe zu
realisieren. Dies ist in PApp nicht nötig, da der persistente 'State' in
einer Datenbank gespeichert wird und nur der (mit 256 Bit verschlüsselte)
Zeiger darauf zum Client übertragen wird. Dadurch werden sensitive Daten
gar nicht erst zum Client übertragen, was natürlich auch Bandbreite
spart. Sollte der Schlüssel einmal bekannt werden kann man zwar auf
andere Sessions zugreifen, die Daten jedoch immer noch nicht verändern
(dieser Fall tritt beispielsweise auch auf, wenn ein kaputtes Proxy
zwischen Server und Client sitzt).

Eine typische PApp-URL sieht übrigens so aus (Applikation "kis", Modul
"abteilungswahl"):

!block verbatim
 /kis/abteilungswahl/NIlRSJNDIfP3AHfVjxLF5F
!endblock

Da eine "Seite" in PApp aus einem Modulbaum besteht, geht es auch
komplizierter:

!block verbatim
 /admin/+admin=poedit+poedit=view--?papp=eTDgL.I-lj9O9lTO3wznTk
!endblock

Zusammen mit einem sicheren Transportprotokoll (z.B. SSL, wobei die
meisten Browser nur ungenügend oder garnicht gegenüber Attacken
schützen, nur so am Rande ;) schützt man sich damit gegen alle Seiten.
Benutzerauthentifizierung über Zertifikate ist auch im Einsatz (mit dem
C<ssl>-Modul von PApp).

H2: Session/User-tracking

Persistente Variablen erfordern Session-Tracking. Benutzerabhängige
Einstellungen (Preferences) darüber hinaus auch User-Tracking. Ersteres
geschieht mit einer Session-ID, die (auf verschiedene Arten) in die
URL-kodiert wird und die alle notwendigen Daten enthält, um die
gewünschte Seite komplett zu erzeugen. Darüber hinaus wird (optional)
ein Cookie benutzt, das aber z.Zt. nur zum Identifizieren des Benutzers
dient, da ich Session-Definitionen per Cookie als Unsinn erachte. Das
Cookie wird auch nur einmal am Tag gesetzt, so daß man auch mit der
Browser-Einstellung "vor Cookies warnen" arbeiten kann.

Eine Anwendung wird darüber informiert, ob eine neue Session begonnen
wurde oder ob sich ein bisher unbekannter Benutzer angemeldet hat, so
daß man Benutzereinstellungen o.ä. initialisieren kann. Dies nützt
PApp selbst, um sich z.B. die Sprache des Benutzers zu merken oder um das
User-Cookie nur einmal täglich zu setzen.

Eine "Sitzung" ist übrigens ein Baum (nicht nur in PApp), der mit dem
ersten "Hit" als Wurzel beginnt. Dadurch ist es unter anderem möglich,
die Anzahl der "Reloads" einer Seite zu bestimmen. Dies ist nützlich,
um potentiell gefährliche Aktionen (z.B. Löschen von Datenbanken,
abschicken von E-mails) nur einmal auszuführen.

H2: Benutzerverwaltung

Da PApp Benutzer (mehr oder weniger) eindeutig identifizieren muss,
implementiert es intern eine eigene Benutzerverwaltung inklusive einer
Unix-artigen Rechtevergabe (es gibt allerdings keinen Super-User im
Unix-Sinne).  In vielen Anwendungen kann man diese gleich mitbenutzen, da
eine eindeutige Benutzer-ID automatisch vergeben wird.

!block verbatim
  Sie sind wahrscheinlich Benutzer Nummer <?$userid:><br/>
 #if auth_p
  Und ausserdem haben sie sich authentifiziert.<br/>
 # if access_p "admin"
  Oh, und "admin"-Rechte besitzen Sie auch noch! Meine Güte!!<br/>
 # endif
 #endif
!endblock

H2: Geschwindigkeit und Skalierbarkeit

Geschwindigkeit war bei der Implementierung von PApp das zweitwichtigste
Ziel (Korrektheit ist das wichtigste ;). Als Marke dient mir ein
Pentium-II 266Mhz-Rechner, auf dem auch komplexe Seiten mit mindestens 15
Hits/Sekunde dargestellt werden, bzw. der Vergleich mit einem ähnlichen
C<Apache::Registry>-Skript.

Das State-Management von PApp verschlingt pro Seite 1-3 Datenbankzugriffe,
die die Zeit bei weitem dominieren (andere Features wie I18n sind im
Prinzip kostenlos).  Da komplexe Seiten im Allgemeinen wesentlich mehr und
kompliziertere Zugriffe enthalten bzw. man ja irgendwie seine Daten
speichern muss, ist dies in der Praxis selten eine Einschränkung
(Ausnahmen gab und gibt es immer). Andere PApp-Features (z.B. im
SQL-Bereich) bringen häufig sogar eine Steigerung der Geschwindigkeit.

Da ich bisher keine Seite fabrizieren konnte, die die 15 Zugriffe/s-Marke
unterschritten hätte, glaube ich noch etwas Spielraum für noch mehr
Features zu haben. Wer sich übrigens fragt, woher diese 15 Hits/s
kommen: 15 Hits ist die Marke, die einen wirklich grossen Server von den
99.99% der restlichen Welt unterscheidet. Hat man auf seinem Server 15
oder mehr Zugriffe pro Sekunde kann man sich meistens auch eine schnellere
Datenbank oder mehrere Rechner leisten: PApp skaliert problemlos auf
mehrere Maschinen.

H2: Ideen, Ideen: z.B. "tied forms"

Ich habe es schon angesprochen: Persistenz von fast allem, zusammen mit
den Möglichkeiten von Perl können einen schon auf Ideen bringen, z.B.
auf eine Bibliothek (editform), die HTML-Formularfelder an Perl-Refrenzen
bindet.

Nun ist es an der Zeit, einmal eine Referenz auf eine SQL-Tabelle zu
erzeugen:

!block perl
 <:
    my $row = new PApp::DataRef 'DB_row',
                                table => "user",
                                where => [id => $userid],
                                delay => 1,
                                autocommit => 1;
 
    # pre-set name
    $row->{name} ||= "<username>";
                                
    ef_begin;
    :><br>__"ID:"   <?ef_string \$row->{id}  ,  5:><:
    :><br>__"Name:" <?ef_string \$row->{name}, 20:><:
    ef_submit __"Update";
    ef_end;
 :>
!endblock

Die Referenz auf die Zeile steht in C<$row> un verhält sich wie eine
Referenz auf einen herkömmlichen Perl-Hash. Das C<autocommit> sorgt
dafür, dass die geänderten Daten automatisch zurückgeschrieben werden
sobald das C<$row>-Objekt gelöscht wird (ausser Scope geht, C<DESTROY>ed
wird). Sie ist lokal (C<my>!) gespeichert, da aber die C<ef_>-Funktionen
die Referenz persistent speichern, wird das Objekt erst auf der nächsten
Seite (also nachdem die Ergebnisse hineingeschrieben wurden!) zerstört,
bzw. die Daten geschrieben. Etwas kompliziert, aber zum Benutzen muss man
die Details ja auch nicht kennen.

Nun macht das Beispiel keine Fehlerüberprüfung, meistens das
schwierigste. Mit PApp kein Problem. Zuerst schalten wir das C<autocommit>
ab, damit die Daten nicht "aus Versehen" geschrieben werden. Ausserdem
übergeben wir die Referenz als Argument an die "nächste" Seite.

!block perl
 <:
    my $row = $A{row}
           || new PApp::DataRef 'DB_row',
                                table => "user",
                                where => [id => $userid],
                                delay => 1,
                                autocommit => 0;
 
    ef_begin -row => $row; # Daten als Argument übergeben
!endblock

Nun brauchen wir ein Flag, das uns sagt, ob der Datensatz fehlerhaft ist
und schon können wir loslegen:

!block perl
   my $err = 0; # Daten fehlerhaft?

   :><br/>__"ID:"   <?ef_string \$row->{id}  ,  5:><:
 #if $row->{id} !~ /^(\d+)$/
      <error>__"The ID must be an integer!"</error>
      <:$err++:>
 #endif
   :><br/>__"Name:" <?ef_string \$row->{name}, 20:><:
 #if 2 > length $row->{name}
      <error>__"The Name must contain at least two characters!"</error>
      <:$err++:>
 #endif
   ef_submit __"Update";
   ef_end;
!endblock

Die Daten schreibt man dann bei Bedarf in die Datenbank:

!block perl
 #if $row->dirty
 # if $err
    <error>__"The entered Data is invalid, please surrender or die (or correct it ;)</error>
 # else
    <:$row->flush:>
    __"The record has been updated."
 # endif
 #endif
 :>
!endblock

H2: "Web-Widgets"

Eine relativ neue "Neuerung" in PApp ist die Einführung von
Web-Widgets. Wie so vieles sind das keine speziellen Objekte, sondern eine
Art der Programmierung, die zwar schon immer möglich warm aber an die man
nicht sofort denkt.

Statt einer ganzen Applikation, die "ganze Seiten" (z.B. ganze
HTML-Seiten) ausgibt, schreibt man eine Applikation, die nur noch
Teilseiten ausgibt, die man in größere Applikationenn einbaut. Dies ist
nicht das gleiche wie ein "include": Der Namensraum (globale Variablen,
state-keys, also Session-Variablen und Preferences) einer solchen
eingebetteten Applikation ist getrennt von der einbettenden Anwendung und
bildet eine Art "Unternamensraum".

Derlei eingebettete Anwendungen sind vollkommen autark, haben ihren
eigenen Zustand ("aktuelle Seite") und können ihre eigenen Formulare,
Links etc. erzeugen die mit anderen Applikationen nicht kollidieren. In
einer Anwendung verwende ich dasselbe Forum-Element, um "Web Chat",
"Kleinanzeigen" und eine "News!"-Seite zu implementieren - jedesmal eine
leicht andere Konfiguration aber derselbe Code.

Da PApp-Applikationen im Prinzip nur grosse Statemaschinen sind (das ist
eine Einschränkung der verwendeten Protokolle, d.h. bis Perl effektive
und schnelle continuations bekommt ;), kann man sie auch einfach in andere
einbauen. Sie können sich gegenseitig beeinflussen, treten sich aber
nicht auf die Füsse.

Also im Prinzip genauso wie ein "Widget" unter X11.

H2: Logging/Protokollierung

PApp protokolliert wesentlich mehr, als man benötigt, legal wäre, und
speicherbar wäre. Da PApp jederzeit in der Lage sein muss, eine ältere
Seite zu regenerieren ("Back & Reload"), speichert es pro Seite die
persistenten Variablen (ca. 300-900 Byte, je nach Applikation, das ist,
wie gesagt, auch eine tolle Sache zum Debuggen).

Aber irgendwann müssen diese Daten wieder weg bzw. statistische Daten
her - nichts ist interessanter, als Zugriffsmuster, Voreinstellungen oder
ähnliches, an dem man ablesen kann, welche Dinge beliebt sind und welche
nicht (klar, man kann auch ganz andere Sachen auswerten, aber das ist
nicht mein Problem).

Beim Aufräumen spielt PApp die einzelnen Zugriffe noch einmal
durch. Statt jedoch Seiten zu erzeugen gibt PApp den einzelnen
Applikationen die Möglichkeit, statistische Daten zu sammeln. Etwas
undokumentierter (wenn es da Abstufungen gibt) ist die Möglichkeit,
globale Daten zu sammeln, aber es geht...

H1: Eine einfache Anwendung mit PApp

What does it look like?

%font "t", prefix "  "
<package name="dunno"> <domain lang="en">

<language lang="en" desc="English"/>
<language lang="de" desc="Deutsch"/>

<database dsn="DBI:mysql:dunnodb"/>
<translate fields="project.name place.name"
           lang="en"/>
<translate fields="project.description"
           lang="mixed" style="auto"/>

<import src="macro/util"/>

<module src="dunno/somepages"/>

</domain> </package>

%page

Modules


        PApp is application centric - one application can consist of many pages (called 'modules').

        Each web-page is (usually) a seperate module.

        Modules and even applications can be nested or embedded.

        State keys can be shared with ease within a session or user context.

        One module == one state of the state machine (http and wap are statemachines!).

%page

A simple module


%font "t", prefix "  "
<module name=""><phtml><![CDATA[
 <html> <title>
    __"PApp - demo", <?localtime:>
 </title>

 <?slink "English", "/lang" => 'en':>
 <?slink "Deutsch", "/lang" => "de":>

 <p><?slink __"To the editor", "editor":>
 <p><?slink __"Edit project 1", "editor",
            projectid => 1:>
   
 </html>
]]></phtml></module>

%page

phtml mode switches


   <:   switch to perl statement mode

   <?   evaluate perl expression

   :>   switch to plain html/text mode

   ?>   switch to interpolated (qq) html/text mode


%page

Another simple module - "editor"


%font "t", prefix " "

   <module name="editor">
   <state keys="projectid" local="yes"/>
   <phtml><![CDATA[
   <:header:>

   #if defined $S{projectid}
   ... edit the specific project
   #else
   ... show a list of projects
   #endif

   <:footer:>
   ]]></phtml></module>

%page

SQL support - the project list


%font "t", prefix " "
<table><tr><th>__"Project"<th>__"Budget"
<:
   my $st =
      sql_exec \my($id, $name, $budget),
          "select id, name, budget
           from project";

   while ($st->fetch) {
      :><tr><td>
         <?slink gettext$name,
                 projectid => $id?>
        <td>$budget
      <:
   }
:>
</table>

%page

SQL support - persistent rows

%font "t", prefix " "
<:ef_begin:>

<:my $row = new PApp::DataRef 'DB_row',
        table => "project",
        where => [id => $S{projectid}]:>

<p>__"Name":
<:ef_string \$row->{name}, 40:>
<p>__"Budget":
<:ef_string \$row->{budget}, 8:>
<p>__"Description":
<:ef_text \$row->{description}, 60, 10:>

<:ef_submit __"Update":>
<:ef_end:>

%page

Internationalization (I18n)


        Strings inside source files can be "tagged"

        Database columns can be tagged

        PApp is unicode-only

        Output conversion (e.g. utf8>latin1, utf8>iso2022jp)

        Translation editor ("poedit") included

%page

Speed


        Speed is slightly worse than Apache::Registry - on simple pages!

        Complex pages usually make no difference (database overhead!)

        Many PApp features deliver a performance that would be tedious to match in plain perl!

        PApp scales to many server machines, if necessary

%page

XML


No, XML is not a feature.

        XML might be nice to computers, it isn't usually for humans, though.

        XML is robust

        XML is fast

        XML is well supported

%page

XML + XSLT = protocol independency


        PApp can support XML as well as HTML

        You can write your pages in XML

        XSLT stylesheets can be applied
                at parse time
                before module execution
                to the resulting output


Thus, PApp applications can easily be made protocol-independent by writing them in XML and using a stylesheet that outputs either HTML, XML, WML or whatever you like!

%page

Dynamic stylesheet example

%font "t", prefix " "
<perl><![CDATA[
   $stylesheet[0] =
      $papp->load_stylesheet("dunno1");
   $stylesheet[1] =
      $papp->load_stylesheet("dunno2");
]]></perl>

<style apply="output"
       expr="$stylesheet[ $S{style} ]">

<module name=""><phtml><![CDATA[
<p/><?slink __"To the edito...
<p/><?slink __"Edit projec...
]]></phtml></module>

...
</style>

%page

"Web-Widgets"


A nice term - what is it?


        PApp applications can be "embedded" into host applications

        With careful coding, reusable objects be created (e.g. a forum module, an ad-banner module etc.)

        Embedded apps come with their own state machine, own environment etc.

        Apply stylesheets to customize, if necessary

%page

PApp


seperates

                layout
                semantics
                language

from each other!

%page

Disadvantages


        perl 5.7.0 + patches is currently required

        many modules are necessary

        mod_perl is currently the only supported platform

        written by one overworked person only

        the api is in flux

        no stable release yet

%page

More info


Dabei ist PApp etwas sehr persönliches - ich habe meine persönlichen
Vorstellungen davon, wie Web/CGI etc. funktionieren sollte, darin
verwirklicht.  Es hat meine Motivation (die sich mit "nie wieder CGI"
zusammenfassen liess) gewaltig gesteigert - Ein einfaches aber dennoch
komplettes Content-Management-System kann man in weniger als 500 Zeilen
hinlegen - für mich ein wichtiger Faktor, denn ich hasse nichts mehr, als
das Rad jedesmal neu erfinden zu müssen.

H2: PApp is Free Software

Although we are not sure wether we'll publish all versions of PApp
under the GPL, or which modules from our own applications might become
standard components (like the forum), we are determined to make PApp free
software. The principal PApp architect (me!) did a lot of free software
modules and works at quite a few free software programs (like GCC or The
Gimp) and is determined to make PApp as free and as powerful as possible.

H1: Disadvantages

PApp is not actually a revolution, judged by its components. It
does, however draw a lot of functionality and ideas into a single,
well-contained package. Nevertheless, there are quite a few reasons on why
{{NOT}} to use PApp, or at least not to use PApp {{YET}}.

* PApp is not yet a released module, its API is in flux (with respect to
  recent features), and not everything is working as it should yet. This
  is fortunately only a question of time.

* Only a single person is currently developing and designing PApp for
  free. This means that advances might sometimes not lead into the
  direction you want, and maybe not in the schedule you want.

* PApp requires the very latest perl - at the moment, this is perl
  5.7 + custom patches, due to the buggy unicode support in earlier
  versions. The latest released PApp module (on CPAN) does not rely on
  unicode, but is already quite outdated with respect to current features.

* There is a total lack of tutorials or introductory courses. While all
  PApp modules are documented, it is very much impossible to learn it
  using the reference documentation alone. Basically a one-day course
  under four eyes is necessary to get you up and running - PApp is
  not trivial. The lost time is generally made up with the increase in
  productivity experienced with PApp, though, similar to learning Perl ;)

A1: References

* PApp is available as a standard module from CPAN, although the current
  version uploaded is very old.

* The PApp homepage is available at the author's homepage, under
  {{URL:http://www.goof.com/pcg/marc/papp.html}}. This page includes
  links to the current manpages. Online demos are, unfortunately, not yet
  available.

* The newest versions of PApp can be accessed using CVS as a sourceforge project,
  at {{URL:http://www.sourceforge.net}}.

* The slides for this presentation will be available at the author's
  homepage, at {{URL:http://www.goof.com/pcg/marc/docs.html}}, shortly
  after the linuxworldexpo.

A2: Apology

I'd like to apologize for any typoes or other mistakes in this
document. It was written in a single session without access to a
spellchecker and so has not been debugged it yet ;)
%page

Revision:	1.2
Committed:	Sun Feb 4 02:01:08 2001 UTC (25 years, 8 months ago) by root
Branch:	MAIN
Changes since 1.1:	+413 -405 lines
Log Message:	* empty log message *