2014-12-30T10:50:14
renee
$ro->code4if('data')->($ro);
Edit: Aber warum muss das unbedingt in eine Anweisung?
Danke Dir!
A: Weil ich das wissen wollte ;)
Edit: Prinzip auch verstanden ;)
Fürs Protokoll:
CODEREF->(ARGS) ist das Schema.
PS/Edit: Es geht hier um ein neues Interface-Design für mein Framework.
$ro ist das Response-Objekt als Instanz der an den URL gebundenen Subklasse. Anstelle des Getters (siehe oben, der liefert die Codereferenz) werde ich die Sache nun umdrehen, das macht den Code verständlicher:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
$ro->execute('init');
if( $ro->param ){
$ro->execute('control');
}
else{
$ro->execute('browse');
}
$ro->execute('trailer');
sub execute{
my $self = shift;
my $key = shift;
$self->{IF}{$key}->($self);
}
Bisher hatte ich
control(), browse(), init(), trailer() als Methoden, welche die Subklasse erbt. Die Vererbung funktioniert einwandfrei, wenn die IF-Methoden in der Subclass definiert sind (Overload, Überschreiben). Was mit Vererbung nicht geht, jedoch: Bisher konnte ich einzelne dieser Methoden austauschen infolge Zuweisung einer externen Package durch Attribute, welche konfiguriert werden können, das wären im Extremfall 4 Attribute, z.B.:
init=xinit
control=xcontrol
browse=xbrowse
trailer=xtrailer
# xinit.pm, xcontrol.pm, xbrowse.pm, xtrailer.pm
Was zur Folge hat, dass jede IF-Methode einen der Konfiguration entsprechenden Code bekommt (auf die Anwendung zugeschnitten). Insgesamt wird dies jedoch sehr schnell unübersichtlich. Daher die Idee, nicht einzelne IF-Methoden auszutauschen, sondern per Konfiguration nur eine einzige Package zuzuweisen:
interface=testinterface
# Package @INC/interface/testinterface.pm wird eingebunden
# Methode $ro->if_config() wird aufgerufen
# in dieser Methode kann der Code für beliebige IF-Methoden
# einfach ausgetauscht werden
Sofern das interface=ATTRIBUTE nicht konfiguriert ist, wird
$ro->ifconfig aufgerufen und wenn es diese Methode in der Subklasse gibt, wird an dieser Stelle der Code für die anderen IF-Methoden (init, browse, control) definiert.
Insgesamt steigert das den Wiederverwendungswert einer Subklasse, z.B. ist
class=TemplateFile nur für die Beschaffung des BODY-Templates zuständig, was, wie der Name andeutet, als Datei vorliegt. Per Konfiguration ist es dann möglich, dieser Klasse das control-Interface zuzuweisen, das Template kann dann Benutzereingaben verarbeiten, ohne dass eine neue Klasse entwickelt werden muss. Bisher passive Seiten können intraktiv werden und dynamische Inhalte bekommen (Letzteres lief bisher nur über das trailer=ATTIBUTE).
Das FW wird kompakter mit weniger Dateien, übersichtlicher und vielgestaltiger. Die Migration auf das neue Interface wird mich Nerven kosten, aber ich denke, es lohnt sich, darüber nachzudenken. Auch wenns keine Sau interessiert.
Last edited: 2015-12-31 09:45:39 +0100 (CET)