[Dresden-pm] Frage zur Implementation von einer Schnittstelle

[Steffen Schwigon]

Hi!

Ich glaube nicht, dass Du dieses Problem mit Technologie lösen kannst,
aber hier trotzdem ein paar Ideen:

1. Nutze ein CPAN-Modul, die Plugins ermöglichen:

   http://search.cpan.org/~muir/Plugins-0.41/

2. Hack selbst Dir was mit Modulen (die Plugins) und Funktionen darin
   zusammen, sinngemäß sowas:

     package MyProj::UserManagement::Plugin::KirmseStyle;
     sub get_display_name {
       my ($vorname, $nachname) = @_;
       return “$vorname $nachname”;
     }
     1;

   Das Interface ist hierbei der Namespace und die sub inklusive ihrer
   Parameter. Jemand anderes schreibt sein Plugin …::SchwigonStyle, etc.

   Dann rein-eval'n und aufrufen.

     my $plugin = get_from_config() || "KirmseStyle"; # config or default
     my $plugin_class = "MyProj::UserManagement::Plugin::$plugin";
     eval "use $plugin_class";
     my $display_name = &{"${plugin_class}::get_display_name"}($vorname, $nachname);

Ich empfehle das nicht wirklich, mache es aber selber auch so.
Es ist zumindest eine technische Variante mit eval.

Kind regards,
Steffen 

Hans-Dietrich Kirmse <hd.kirmse at gmx.de> writes:
> Hallo,
>
> ich komme wieder mit einer sicherlich exotischen Frage:
> wie gestaltet man eine Schnittstelle für eine "externe" Funktion.
>
> Ich meine damit Folgendes: ich habe für unser Schulserverprojekt eine
> ganze Reihe von Perl-Scripten zur User- und Rechnerverwaltung
> erstellt. Diese Scripte habe ich dann in ein Debian-Paket gesteckt und
> die werden darüber eingespielt.
>
> Nun ist es aber so, das diese Scripte nicht die Anforderungen von
> allen potentiellen Nutzern erfüllen werden. Es soll jetzt die
> Möglichkeit eingerichtet werden, dass andere Entwickler Scripte
> (Funktionen) schreiben, die sich in die von mir bereitgestellten
> Funktionen einklinken.
>
> Ein einfaches Beispiel: Beim Versetzen von Usern bzw. Klassen wird
> durch mein Script folgendes Codefragment aufgerufen:
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> # wir bilden den kompletten Name
> $name_curr = $forename_curr . ' ' . $lastname_curr;
>
> # und tragen den in den LDAP ein
> $mesg = $ldap->modify( $entry->dn,
>                        replace => { cn           => $name_curr,
>                                     sn           => $lastname_curr,
>                                     givenName    => $forename_curr,
>                                     displayName  => $name_curr } );
> $mesg->code and die "Abbruch: $mesg->error";
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> Es wurden Wünsche geäußert, dass der displayname anders gebildert
> werden sollte, nämlich neben dem Name auch die Klasse angegeben
> werden. Andere lehnen das grundsätzlich ab, weil die Klasse ein
> eigener Entry im LDAP ist und es damit zu nicht gewollten Redundanzen
> kommt.
>
> Lösung des Problems, das für die, die das Attribut 'displayName'
> anders haben wollen, ein Funktion bereitzustellen, die eben für diesen
> User die Klasse im LDAP sucht und dann einen anderen Displaynamen
> bereitstellt.
>
> Das Problem ist nicht, wie so eine Funktion aussieht - das ist eher
> trivial. Das Problem ist, wie mache ich das, dass ein anderer
> Programmierer eine solche Funktion erstellen kann, diese in ein Modul
> steckt, dieses Modul in ein Debian-Paket steckt und wenn dieses
> Debian-Paket eingespielt wird, dass dann automatisch diese Funktion
> aufgerufen wird.
>
> Diese Sache hier mit dem Displayname ist dabei nur ein Beispiel. Es
> geht überhaupt darum, wie man so eine Schnittstelle implementiert. Ich
> habe dazu in der Literatur und im Netz (aber nur deutschsprachig)
> nicht gefunden. :(
>
> Ich hoffe, ich konnte mein Problem verständlich genug ausdrücken.
>
> Für jeden Hinweis, Idee wäre ich sehr dankbar.
>
> Viele Grüße
> Hans-Dietrich
> _______________________________________________
> Dresden-pm mailing list
> Dresden-pm at pm.org
> http://mail.pm.org/mailman/listinfo/dresden-pm
>

-- 
Steffen Schwigon <ss5 at renormalist.net>