nicht angemeldet
ich würde das ganze noch etwas entkoppeln falls es dich interessiert:
Ja. Interessiert mich immer.
Ich bin ja jetzt meine Begehrlichkeiten im Implementieren.
Sprich, welche API MUSS zwischen Plugin und dem Handler bestehen.
sub getUserPlugin
{
# sprechende variablennamen dokumentieren den code
my $textToParse = @_;
OK...
my $content = eval { user_plugin($textToParse) };
$content ||= "WARNING";
# das html wird NUR hier generiert, dadurch kann
# man es später ändern wenn man den <b> tag leid ist
return '<b class="warning">'.$@.'</b>' if $@;
'<p class="info">'.$content.'</p>';
Eigentlich sollte die normale Rückgabe eines Plugins in
q( <div class="plugin PLUGINNAME">...</div> )
landen. Deshalb ist das hier ungünstig.
}
sub user_plugin
{
my $textToParse = shift or return '';# der übersichtlichtkeit halber und eigentlich
# sollte man sowas irgendwo statisch definieren zwecks geschwindigkeit
Ja.. Da sind noch andere Regex. Die eventuell in einer dispatch Tabelle gespeichert werden.
my $moduleNamePattern = /[name:([A-Za-z]+)]/;
my $parameterPattern = /[param:([a-z0-9_.,-]+)]/;
my $parameterSeparatorPattern = /,/;
die('Plugin-Name nicht spezifiziert') unless my $plugin = ($textToParse =~ $moduleNamePattern)[0];
Perl Critic (habe mich heute damit befasst) rät von dieser unless Schreibweise ab.
# warum doppel gemoppelt noch auf existenz und lesbarkeit prüfen!
Profifrage:
Was liefert -r $file in einem beliebigen Kotext ohne auf -e $file zu prüfen?
Warum kann ich bei -e $file auch -r $file voraussetzen?
# wenn es nicht geladen werden kann, dann kanns einfach nicht geladen werden
Und lässt den Anwender eines CMS im Regen stehen...
my $modulePath = $Path{cgidir} . "EHFPlugins/". $plugin .'.pm';
eval{ require( $modulePath ) };
# $self->log('could not load plugin ', $plugin, ' because ', $@);
Es ist interessant, was Perl Critic sagt bezüglich $@. Ich habe das geändert zu:
eval{
require( 'EHFPlugins/'.$plugin.'.pm' );
1;
} or do {
return '<b class="warning">Plugin '.$plugin.
' konnte unerwartet nicht gestartet werden.</b>'.$@;
};
Allerdings hat es etwas für sich, den require Test über den absoluten Pfad auszuführen, und -e und -r erst in der or do{ } zu praktizieren, um die richtige Errormessage zurückzugeben.
die('Plugin '.$plugin.' konnte unerwartet nicht gestartet werden.') if $@;
die ist hier fehl am Platze.
# auch hier ::p ist ungelücklich kurz und nichtssagend gewählt
my $method = $plugin . '::p';
Es spielt keine Rolle. wie ich das Ding benenne. Dokumentieren muss ich die Perl-Plugin API und die EHF-Code-Plugin API ja sowieso.
Ich studiere noch über den geeigneten Namen.
my @param = split ($parameterSeparatorPattern, ($textToParse =~ $parameterPattern)[0]);
Das solltest du der Ordnung halber viel früher ausführen.
# auch beim methoden aufruf am plugin kann etwas schiefgehen!
my ($error, $content) = eval
{
no strict 'refs';
$method->(@param);
};die($content) if $error || $@;
$content;
Werde mir etwas mit Überlebenschancen ausdenken.
}
>
> hth
>
> ps. ich habe es nur geschrieben, nicht getestet
Weiss ich...
Ich werde das Gute daraus ziehen.
mfg Beat
--
><o(((°> ><o(((°>
<°)))o>< ><o(((°>o
Der Valigator leibt diese Fische
Struppi