Best Practice : "local < Variable >;" & Bereitstellung (Allgemeines zu Perl)

[thread]21192[/thread]

Best Practice : "local < Variable >;" & Bereitstellung

Leser: 11

Articles: hide open all | hide show old branches

+7 replies
YAPD

2021-05-12 13:46
User since
2015-09-20
146 Artikel
BenutzerIn
Hi Leute,

ich habe eine Anwendung, in der ich die Objekte über einen
Object Manager zur Verfügung stelle. Diese rufen ich hier
folgendermaßen auf :

my $OM = Kernel::OM -> New( );
$OM -> Load( 'Kernel::Internals::Logs' );

Näheres zu meiner Struktur könnt ihr aus diesem
Thread erlesen :

Quote
Aufruf von Sub - Klassen mit variablen Namen

Nun möchte ich natürlich, dass das Objekt des Objekt - Manager ( $OM )
überall verfügbar ist, z. B. in 'Kernel::Internals::Logs'.

Ist die beste Möglichkeit, die Variable als "local" zu definieren
und so das Objekt aufzurufen ? Der Code wäre entsprechend :
Code: (dl )

1 2

local $Kernel::OM = Kernel::OM -> New( ); $Kernel::OM -> Load( 'Kernel::Internals::Logs' );
Und der Aufruf in 'Kernel::Internals::Logs' :
Code: (dl )

1 2 3

if ( !$Kernel::OM ) { print 'Fehler bei der Initialisierung des Kernels des Objekt - Managers !' } my $Config = $Kernel::OM -> Load( 'Kernel::Config' )
Es funktioniert so zwar anscheinend, aber ich möchte halt gerne
wissen, ob man es besser oder anders machen könnte.

Vielen Dank !

Beste Grüße
YAPD
Last edited: 2021-05-12 15:27:34 +0200 (CEST)
Yet Another Perl Developer
- +5 replies
- haj
  
  2021-05-12 16:24
  User since
  2015-01-07
  557 Artikel
  BenutzerIn
  Nun ja, local ist nicht das die richtige Schlüsselwort dafür. Mit local definierst Du keine Variable, sondern Du setzt dynamisch einen Wert für eine "anderswo" definierte. Das funktioniert nur, weil Du die Variable explizit mit einem Package qualifizierst.
  
  Ein mögliches Verfahren wäre, in Deinem Hauptskript die Variable nicht als lexikalische Variable mit my, sondern als global verfügbare mit our zu deklarieren:
  
  Code (perl): (dl )
  
  our $OM = Kernel::OM -> new( );
  
  Dann kannst Du den Objektmanager aus jedem Teil Deines Codes als $main::OM oder kurz $::OM verwenden (Dein Hauptskript läuft, wenn nichts anderes angegeben, im Namensraum main, und den kann man auch weglassen).
  
  Etwas mehr im Sinn der Objektorientierung: Ich nehme an, Du hast nur einen Objektmanager. Man nennt sowas dann ein "Singleton". Na ja, seit dem Film manchmal auch ein "Highlander-Objekt".
  
  So eine Singleton-Klasse hat in der Regel kein new, denn sonst könnte ja jeder Teil Deines Programms einen neuen OM bauen. Statt dessen gibt es eine Methode init, die das Ding einmal einrichtet, und eine Methode instance, die dieses Objekt liefert. Das sind beides Klassenmethoden. In Kürze:
  
  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 34 35 36 37 38 39
  
  use 5.024; use strict; use warnings; package Kernel::OM { my $OM; sub init { my $class = shift; my %params = @_; die "Nur eine Initialisierung, bitte!" if $OM; $OM = bless { %params }, $class; return $OM; } sub instance { my $class = shift; die "Noch nicht initialisiert!" unless $OM; return $OM; } } # ------- Benutzt wird das wie folgt: use Data::Dump qw/dump/; # Einmal, am Anfang: Kernel::OM->init (irgend => 'welche', para => 'meter') or die "Hoppla: Kein Objektmanager!"; # und dann, von überall her: my $om = Kernel::OM->instance; dump $om;
  - +4 replies
  - BernhardSchmalhofer
    
    2021-05-13 10:59
    
    User since
    2009-03-26
    56 Artikel
    BenutzerIn
    
    Ich nehme an dass es sich bei Applikation um OTRS oder OTOBO handelt. Dort wird $Kernel::OM als globales Object verwendet. Deshalb ist die Variable auch auch im globalen Namensraum Kernel definiert.
    
    Normalerweise würde es genügen $Kernel::OM einmal am Start des Programmes zu initialisieren. OT[RS|OBO] läuft aber normalerweise als Webapplikation unter Apache/mod_perl oder Gazelle. Es handelt sich also um eine Instanz des Perl-Interpreter welche über mehrere Anfragen persistent ist. Man will aber dass die Objekte für jeden Request neu erzeugt werden. Man benutzt also local damit für jeden Request eine frische Inkarnation von $Kernel::OM verwendet wird.
    
    Diese Ansatz scheint zu funktionieren, ich bezweifle aber dass er best practice ist.
    - +3 replies
    - YAPD
      
      2021-05-13 11:25
      
      User since
      2015-09-20
      146 Artikel
      BenutzerIn
      
      Hi Bernhard,
      
      ja das hast du völlig richtig erkannt ;)
      
      Die Grundstruktur basiert auf OTRS, ich habe mich daran orientiert und will darauf meine eigene Anwendung aufbauen. Außer dem Objekt - Manager ist es aber eine eigene Entwicklung.
      
      Ja ich dachte mir auch, dass dies bestimmt nicht die Best Practice ist. Der Vorschlag von haj mit "our" funktioniert
      aus den besagten Gründen ja nicht.
      
      Außerdem ist OTRS zwar ganz passabel, man sollte sich allerdings höchstens daran orientieren, aber es nicht nachbauen.
      Mir kommt es vor als wäre OTRS unter starkem Termindruck entworfen, das Error - Handling z. B. und andere Funktionen, auch im Objekt Manager sind sicherlich nicht optimal gelöst.
      
      Beste Grüße
      YAPD
      Last edited: 2021-05-13 11:38:00 +0200 (CEST)
      Yet Another Perl Developer
      - +2 replies
      - haj
        
        2021-05-13 14:26
        
        User since
        2015-01-07
        557 Artikel
        BenutzerIn
        
        2021-05-13T09:25:30 YAPD
        Die Grundstruktur basiert auf OTRS, ich habe mich daran orientiert und will darauf meine eigene Anwendung aufbauen. Außer dem Objekt - Manager ist es aber eine eigene Entwicklung.
        
        Das klärt einiges! Ich kenne OTRS nicht und wusste nicht, dass es sich um eine Web-Anwendung mit persistentem Interpreter handelt. Wenn jeder Request einen eigenen Objektmanager braucht, dann ist das kein Singleton. Dagegen ist local sehr wohl geeignet, eine nur für einen Request gültige Instanz zu erzeugen. Andererseits sollte es auch mit our funktionieren, wenn jeder Request das Ding neu aufbaut: Der Unterschied ist, dass bei local der Wert am Ende des Gültigkeitsbereich automatisch verschwindet, während er bei our erst mit dem nächsten Request wieder überschrieben wird.
        
        Wenn der Objektmanager von "überall" aus der Anwendung erreichbar sein soll, dann gibt es als Alternative zur lokalisierten Package-Variablen die Möglichkeit, ihn an die Request-Daten des Webservers dranzuhängen, die ja die gleiche Lebensdauer haben. Das ist "anders" - aber ob's besser ist, ist wohl Geschmackssache.
        
        BernhardSchmalhofer
        
        2023-06-02 17:19
        
        User since
        2009-03-26
        56 Artikel
        BenutzerIn
        
        Das mit dem Anhängen an die Request-Daten geht nicht einfach, weil der Objectmanager auch an Stellen benutzt wird, die mit den Request-Daten nichts zu tun haben. Die Crux ist auch dass DESTROY-Handler zum Aufräumen der Objekte benutzt werden, da ist nicht immer garantiert dass die DESTROYs in der richtigen Reihenfolge aufgerufen werden.
        Siehe auch https://github.com/RotherOSS/otobo/discussions/111... .
- rosti
  
  2023-06-03 09:35
  
  User since
  2011-03-19
  3492 Artikel
  BenutzerIn
  
  In Anlehnung an PHP::PDO::FETCH_OBJECT
  http://rolfrost.de/fetchobjects.html
  
  könntest Du ja auch Deine Objekte in MySQL speichern. Wichtig ist eine connection_cached und der restliche Code könnte so aussehen:
  
  Siehe Artikel: http://rolfrost.de/objects.html
  Last edited: 2023-06-03 15:19:14 +0200 (CEST)

View all threads created 2021-05-12 13:46.