Opened by rosti at 2014-05-09 10:51
User since
2011-03-19
3688 Artikel
BenutzerIn
![[Homepage]](/battie/theme/default/homepage.gif)
2011-03-19
3688 Artikel
BenutzerIn
Klassenbindung, Routingtable: http://rolfrost.de/routes.phtml
Die Routingtable ist eine ini-Datei damit sie händisch editierbar ist. Diese ini jedoch wird nicht in diesem Format aufgestellt, sondern als ein Hash-of-Hashes in eine Binärdatei serialisiert. Diese Binärdatei hat gegenüber der ini-Datei den Vorteil. daß sie wesentlich performanter eingelesen wird, sie wird bei jedem Request eingelesen. Im Falle mod_perl oder FastCGI ist sie speicherresident, wird also nur beim Start des Servers einmal eingelesen.
Der andere Vorteil der Binärdatei gegenüber der ini ist, daß sie mit jeder PL einfach gelesen werden kann, also in c, c++, php, perl, wie auch immer, der Algorithmus ist ganz einfach.
Der Deployment-Prozess bgeinnt also mit der Umwandlung der ini in eine Binärdatei auf meinem lokalen PC. Neben den in der ini konfigurierten URLs werden der Binärdatei weitere Seiten hinzugefügt, die direkt aus dem lokalen Dateisystem geladen werden. Diese Dateien beinhalten nur die Attribute wie title und descr und den HTML-Body. Derzeit umfasst meine Repos. rund 400 solcher Dateien (Artikel).
Damit ich bei einzelnen Seiten nicht jedesmal die ganze Binary hochladen muss, gibt es die Möglichkeit, einzelne Seiten direkt an einen Webservice zu senden, per Shortcut direkt aus dem Editor heraus. Das Publizieren ist somit extrem einfach. Der Webservice baut die Einzelseite dann direkt auf dem Server in die Binary ein:
Und das ist alles deswegen so einfach, weil jedes Request/Response-Objekt eine Referenz auf die Binary als Objekteigenschaft besitzt. Das ist das ganze Content-Management.
Die Routingtable ist eine ini-Datei damit sie händisch editierbar ist. Diese ini jedoch wird nicht in diesem Format aufgestellt, sondern als ein Hash-of-Hashes in eine Binärdatei serialisiert. Diese Binärdatei hat gegenüber der ini-Datei den Vorteil. daß sie wesentlich performanter eingelesen wird, sie wird bei jedem Request eingelesen. Im Falle mod_perl oder FastCGI ist sie speicherresident, wird also nur beim Start des Servers einmal eingelesen.
Der andere Vorteil der Binärdatei gegenüber der ini ist, daß sie mit jeder PL einfach gelesen werden kann, also in c, c++, php, perl, wie auch immer, der Algorithmus ist ganz einfach.
Der Deployment-Prozess bgeinnt also mit der Umwandlung der ini in eine Binärdatei auf meinem lokalen PC. Neben den in der ini konfigurierten URLs werden der Binärdatei weitere Seiten hinzugefügt, die direkt aus dem lokalen Dateisystem geladen werden. Diese Dateien beinhalten nur die Attribute wie title und descr und den HTML-Body. Derzeit umfasst meine Repos. rund 400 solcher Dateien (Artikel).
Damit ich bei einzelnen Seiten nicht jedesmal die ganze Binary hochladen muss, gibt es die Möglichkeit, einzelne Seiten direkt an einen Webservice zu senden, per Shortcut direkt aus dem Editor heraus. Das Publizieren ist somit extrem einfach. Der Webservice baut die Einzelseite dann direkt auf dem Server in die Binary ein:
Code (perl): (dl
)
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
my $control = sub{ my $self = shift; if( $self->param('pub') ){ my $hunt = $self->thaw(*STDIN); my $h = $hunt->{1}; my $url = $h->{url}; $self->{BIN}{$url} = $h; # evntl. gibt es eine Datei in search unlink "$self->{FILEDIR}/search".$url; # BIN zurückschreiben my $fh = IO::File->new; $fh->open("$self->{FILEDIR}/dbf.bin", O_BINARY|O_RDWR|O_TRUNC|O_CREAT) or die $!; $self->freeze($self->{BIN}, $fh ); $self->{CONTENT} = "Written: $url"; }
Und das ist alles deswegen so einfach, weil jedes Request/Response-Objekt eine Referenz auf die Binary als Objekteigenschaft besitzt. Das ist das ganze Content-Management.