Rostis Framework - #196851 (Projekte)

rosti

2025-02-04 11:00

User since
2011-03-19
3548 Artikel
BenutzerIn

Quote
Genau aus diesem Grund lege ich die Sourcen für mein Framework nicht komplett offen sondern nur soweit, dass vielleicht mal einer kommt und sagt: Will ich auch haben.

Die Sourcen sind trivial. Von daher kommt es gar nicht darauf an, Sourcen offenzulegen sondern darum, den Aufbau und insbesondere den Sinn und Zweck einer objektorientierten Programmierung zu verstehen. Erster Punkt ist die Klassenbindung:

Code: (dl )

Beliebige HTML-Seiten mit c++ ausliefern
class: HTMLfile
descr: Eine Klasse HTMLfile zur Erstellung der Response
file: /about.html
parent: /cpp.chtml
title: Beliebige HTML-Seiten mit c++ ausliefern
url: /about.chtml

Hierbei spielen Post/Get-Parameter noch gar keine Rolle. Die Klassenbindung ist nur die statische Route zur Klasse deren Instanz bei einen Request erstellt wird. Und diese Instanz schnappt sich weitere Eigenschaften die da konfiguriert sind wie Titel und Beschreibung einer Seite die der Server ausliefert. Sind Parameter im Spiel, also Nutzereingaben wie im nächsten Fall

Code: (dl )

VLSM CIDR Subnet-Calculator für IPv4 mit Perl
class: IP4Calc
descr: Berechne ein Netz für IPv4 und kalkuliere die Subnetze
no_cache: 1
parent: /netzwerk
short: NetCalc
title: VLSM CIDR Subnet-Calculator für IPv4 mit Perl
url: /netcalc.html

ruft die Klasseninstanz eine Methode control() wo das Ergebnis kalkuliert und die Antwortseite zusammengestellt wird. Mit oder ohne Parameterverarbeitung, der Ablauf ist bei jedem Request stets derselbe. Also definiert mein FW ein Interface in Gestalt einer Handvoll Methoden die nacheinander immer in derselben Reihenfolge aufgerufen werden. Und in jeder dieser Methode hat die Instanz der an den URL gebundenen Klasse Zugriff auf alle zu diesem URL konfigurierten Eigenschaften.

Und ja, ich habe mir auch andere Frameworks angschaut und dabei festgestellt, daß keines von denen so arbeitet. Insbesondere die Trennung von Code und Konfiguration und die konsequente Anwendung der objektorientierten Programmierung.

Zweiter Punkt ist eine Factory. Erst gestern habe ich eine kleine Eweiterung geschrieben, den Einbau der Checksumme in einen Meta-Tag. Hierzu ist die Interface-Methode start_html() zuständig und in dieser Methode haben wir, wie in jeder anderen Methode die Instanz der gebundenen Klasse zur Verfügung. Also rufen wir mit dieser Instanz einfach die Methode checksum():

Code (perl): (dl )

1
2

    # checksum
    $stash->{checksum} = $self->checksum($ENV{HTTP_HOST}.$self->{URL}.$ENV{QUERY_STRING});

wobei die Methode checksum in einer dedizierten Datei definiert ist:

Code (perl): (dl )

# Datei checksum.pm
use strict;
use warnings;
use Digest::MD5 qw(md5_hex);

sub checksum{
    my $self = shift;
    my $s = shift;
    return md5_hex($s);
}

1;

Was den Vorteil hat, daß im Falle einer Entscheidung ob eines anderen Verfahren der Checksummenbildung eben nur diese eine Datei anzufassen ist. Infolge der strikten Trennung funktionaler Methoden und Module und der Trennung von Code und Konfiguration ist das FW beliebig erweiterbar ohne Änderung der Core-Methoden. Möglich ist auch, die Interface Methoden browse(), init(), control() in einer dedizierten Datei zu definieren und dieses Interface per Konfiguration einem URL als Eigenschaft zu verpassen:

Code: (dl )

class: DBFileResponse
descr: Unicode und die Normalform C für UTF-8-kodierte Zeichen 
interface: nfc
no_cache: 1
parent: /unicode
title: Text run is not in Unicode Normalization Form C
url: /nfc.html

Was diesen URL im Nachhinein zur Verarbeitung von Benutzereingaben (Post/Get) befähigt. Ebenso ist es auf diese Art und Weise möglich über Platzhalter (jede Seite ist ein Template) dynamische Inhalte in beliebige Seiten einzubauen ohne den Code in HTML einzubetten (was embed Perl und PHP machen).

Lust auf Framework? Nur zu. Alles was Sie brauchen ist eine gute Idee ;)

http://blog.rolfrost.de/

The art of steam.