Techniken für Plugin-Einbindung (Allgemeines zu Perl)

[thread]16752[/thread]

Techniken für Plugin-Einbindung

Tags: perl5 plugin Ähnliche Threads

Leser: 23

Articles: hide open all | hide show old branches

+4 replies
marky

2011-09-24 12:58

User since
2003-08-15
215 Artikel
BenutzerIn

Hallo,

ich bin derzeit an der Entwicklung eines grossen Systems und überlege nun gerade wie man Plugins entwickeln könnte. Es gibt 3 Arten von Plugins

- Tempalte-Plugin, das ist funktionen, die direkt aus den Templates aufgerufen werden und auf die Grundwerte des System zugreifen können, das klappt gut und ist fertig.

- Applikationsplugins, das ist letztlich eigene Anwendungen, die per Link unabhängig vom Rest aufgerufen werden und irgendwas machen, das ist auch kein Problem

- Core-Plugins - hier suche ich noch nach einem guten Konzept, dh. überschreiben und erweitern von bestehenden Funktionen

Für das Überschreiben würde ich mir vererbung arbeiten und für anpassen mit Hooks an wichtigen Stellen. Das Problem mit dem Überschreiben ist aber, dass man doch sehr viele kleine Subs machen muss, damit das einigermassen flagil ist, im zweifel jede Zeile in eigenes sub - was natürlich nicht so richtig schnell ist, wenn für jede kleine Funktion 50 subs aufrufen muss. Und übersichtlich ist das auch nicht gerade.

Ich habe mir auch schon diverse grössere Perl-Projekte angeschaut, aber so richtig überzeugt hat mich das alles noch nicht.

Gibt es irgendwo ein Buch, eine Seite - irgendwas wo etwas allgemeiner auf die Problematik eingegangen wird und verschiedene Möglichkeiten diskutiert werden?

Oder gibt es ein System, wo ihr sagt, da ist das wirklich gut gemacht.

Gruss Marky
Mfg
Markus - http://www.perlunity.de -
- +2 replies
- topeg
  
  2011-09-24 14:19
  User since
  2006-07-10
  2611 Artikel
  BenutzerIn
  Bei Templateplugins würde ich zu einer Klasse raten, die zwangsweise von einer andern erbt:
  
  Code (perl): (dl )
  
  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33
  
  my $plugincode=load_code(); my $dataobj=get_data_object(); $plugincount++; $pugincode=<<EOC; { package PLUGIN::PLUGINS::$pugincount; use base 'PLUGIN::BASE'; use strict; use warnings; $plugincode; 1;} EOC my $pluginobj; if(eval(plugincode)) { $pluginobj=eval("PLUGIN::PLUGINS::$pugincount->new($dataobj)") if(!$pluginobj) { # create error } } else { # copmile error } #... $pluginobj->mach_was();
  
  Wenn man ganz vorsichtig sein will, kann man auch Forken und über IPC mit dem Plugin kommunizieren. Das sähe gar nicht so anders aus. Nur das Paket, von dem Geerbt wird, ist komplexer.
  
  Beu Codeplugins würde ich auf Signalhandler setzen, die kann man überall einfügen und machen am wenigsten Probleme, finde ich.
  Das Laden wäre ähnlich zu dem was ich oben gezeigt habe, nur dass kein Datenobjekt übergeben wird sondern das "System"-Objekt.
  
  Im Plugin
  
  Code (perl): (dl )
  
  1 2
  
  my $id=$obj->handler_add('aktion',sub{ ... },@options); $obj->handler_del($id);
  
  im System Code
  
  Code (perl): (dl )
  
  $obj->handler_exec('aktion',@data) if($obj->handler_exists('aktion'));
  
  Hier könne man auch Einbauen, dass Code der nicht "true" zurück liefert aus der Handlerliste gelöscht wird.
  - marky
    
    2011-09-27 10:12
    User since
    2003-08-15
    215 Artikel
    BenutzerIn
    
    Hallo,
    
    ich mache das ganz anders, die Hooks über die Signale könnte man noch ändern, das muss ich mal anschauen, wie man das am besten implementiert, die Tempalte-Plugins laufen so
    
    Code: (dl )
    
    1 2 3 4 5 6 7 8 9 10 11 12
    
    while ( $tmpl_line =~ /\[OS_TMPLPLUGIN:(\w+):(\w+):(.*?)\]/g ) { my ($tpath,$tfunc,$tfval,$tpvalue) = ($1,$2,$3,'') ; if ( -e "pfad/Tmpl/$tpath/$tfunc.pm" ) { eval "require Tmpl::$tpath\::$tfunc" ; die "Fehler bei Einbindung Template-Plugin : Tmpl::$tpath\::$tfunc : $@\n" if ($@) ; my $tplg = $tfunc->new(\%CONFIG,\%PARA,$tfval); $tpvalue = $tplg->out ; }
    
    dann muss man nicht den Code evaluieren. Und die Plugins an sich sehen alles gleich aus vom Aufbau.
    
    Das andere habe ich jetzt noch etwas anders gelöst und zwar über AUTOLOAD, meine Frage dabei ist jetzt, dass man immer liest, dass AUTOLOAD teuer ist - ist das aber immer noch so - in der jetztigen Lösung würden quasi die Funktionen immer über AUTOLOAD laufen.
    
    Siehst Du ein Problem, was die Performance angeht? Die Lösung ist nämlich wirlich genial. Ist nur ein bisschen viel zum Posten, aber jetzt gibt es die Möglichkeit, ein Plugin vor und nach der Funktion auszuführen und die Funktion selber zu überschreiben.
    
    Hier mal das Autoload
    
    Code: (dl )
    
    1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60
    
    sub AUTOLOAD { my ($self,$arg1) = @_ ; my @func = split(/\:\:/,$AUTOLOAD) ; my $f = $func[-1] ; my $fb = $f . "_beforeEvent" ; my $fa = $f . "_afterEvent" ; my $fo = $f . "_overEvent" ; print "FUNC : @func ($func[-1]) \n" ; print "Obj : " , $self->{'modclass'} , " ( $self->{'modobj'} ) \n" ; print "AUTOL : $AUTOLOAD | @_ \n\n" ; ### #Ausgabe vorher if ( $self->{'plugclass'}->can($fb) ) { print "Methode $self -> $fb vorhanden\n" ; $self->{'plugclass'}->($f . "_beforeEvent")($arg1) ; } ### #Eigentliche Funktion if ( $self->{'plugclass'}->can($fo) ) { print "Ausgabe OVERfunktion\n" ; $self->{'plugclass'}->$fo($arg1) ; } elsif ( $self->{'modobj'} && $func[-1] ) { print "Ausgabe Standardfunktion\n" ; $self->{'modobj'}->$f($arg1) ; } ### #Ausgabe nachher if ( $self->{'plugclass'}->can($fa) ) { print "Methode $self -> $fa vorhanden\n" ; $self->{'plugclass'}->$fa($arg1) ; } print "\n-----------\n\n" ; } sub DESTROY {} 1 ; Aufruf wäre so my $pobj = Plugin->new('TestClass','TestClassPlug') ; $pobj->t1('T1T1T1') ; $pobj->t2('T2T2T2') ;
    
    Das ist mal wirklich eine sehr sehr flexible Lösung, aber halt mit AUTOLOAD erkauft, die alternative wäre nur, dass man eine exec-Funktion macht, dann muss aber jede Funktion über die exec aufrufen, was vom Code her nicht so transparent aussehen würde, anstelle von
    
    $pobj->t1('T1T1T1') ;
    
    dann
    
    $pobj->exec('t1','T1T1T1') ;
    
    und man könnte auf das AUTOLOAD verzichten, das scheint mir aber ein bisschen exotisch zu sein.
    
    Gruss Marky
    Mfg
    Markus - http://www.perlunity.de -
- rosti
  
  2011-09-27 20:27
  
  User since
  2011-03-19
  3197 Artikel
  BenutzerIn
  
  hi Marky,
  
  ich gehe mal davon aus, dass es eine Webanwendung ist, und so habe ich das da gemacht:
  
  Serverseitig gibt es eine Tabelle mit allen URLs, die requestet werden dürfen (ohne Query_String). Nennen wir diese Sammlung 'Objects.bin', die Elemente sind Response-Objekte (RO). Jedes RO hat Eigenschaften, neben Title, Descr gibt es u.a. Eigenschaften worüber die Berechtigung abgewickelt wird.
  
  Eine weitere wichtige Eigenschaft ist das Attribut iswas:
  
  /index.html, iswas=rabbit
  /impressum.html, iswas=template
  /find.html, iswas=findform
  
  An iswas stehen die Namen der Methoden, welche über das RO aufgerufen werden zur Darstellung des Body.
  
  rabbit lädt den Body als HTML aus der Objects.bin; Keine Parameter.
  template lädt das Template aus der Objects.bin; sofern es Parameter gibt, wird eine Methode gerufen, die namentlich im Attribut control=feedback genannt ist. Die Methode feedback ist der Controler gemäß MVC, verarbeitet die Eingaben und bestückt das Template, was dann ausgegeben wird.
  
  As least, findform ist die Methode, welche beim Request auf /find.html aufgerufen wird, sofern es Parameter gibt, steht der Name der Methode namenlich fest: x_findform (Controler)
  
  Plugins lassen sich somit ganz fein einbauen, wenn eine neue Methode gebraucht wird, die wird einfach der Klasse, welcher das RO angehört, hinzugefügt.
  
  Neue Templates: Template schreiben und den Controler, fertig.
  
  Das Ganze läuft so auf meiner Website. Kannst Du damit was anfangen?
  
  --Rolf
  
  PS. Edit: Die Bindung der URLs an Methoden ist vom Code getrennt, die Konfiguration. Zwischen URLs und iswas=Methoden gibt es eine n:n Beziehung.
  
  Also, mein Plugin-Konzept: Es gibt keine einzelnen Scripts mehr, sondern entweder Template+Control-Method oder Methoden method+x_method im iswas-Attribut.
  
  Alles zusammen läuft derzeit über ein CGI-Script als ResponseHandler, kann jedoch auch über mod_perl laufen oder über ein FastCGI.
  Last edited: 2011-09-27 20:41:43 +0200 (CEST)

View all threads created 2011-09-24 12:58.