Variablen an Package übergeben (Allgemeines zu Perl)

[thread]17456[/thread]

Variablen an Package übergeben

Tags: perl5 Ähnliche Threads

Leser: 15

Articles: hide open all | hide show old branches

+8 replies
Gast Muffi

2012-06-01 16:33
Ich steh grad am Schlauch.
Folgende Situation:
Code (perl): (dl )

1 2

use MySQLModul; use NaechstesModul;
NaechstesModul hätte gerne beim use zum Initialisieren eine DB-Verbindung von MySQLModul, MySQLModul weiss aber Username und Passwort nicht bereits beim use.

Momentaner Lösungsansatz, der mir allerdings nicht so besonders gefällt:
Code (perl): (dl )

1 2 3

use MySQLModul; MySQLModul::connect(...); require NaechstesModul;
Krieg ich irgendwie Username und Passwort halbwegs hübsch an das MySQLModul oder denk ich grad in die völlig falsche Richtung?
Last edited: 2012-06-01 16:40:09 +0200 (CEST)
- +4 replies
- pq
  
  2012-06-01 16:42
  User since
  2003-08-04
  12208 Artikel
  Admin1
  warum muss die db-verbindung schon beim use gemacht werden?
  und wie übergibst du die db-verbindung an das modul? etwa über eine globale variable? ungut.
  
  Code (perl): (dl )
  
  1 2 3 4
  
  use MySQLModul; use NaechstesModul; my $dbh = MySQLModul::connect(...); NaechstesModul->init($dbh);
  
  so in die richtung würde ich das machen.
  Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. -- Damian Conway in "Perl Best Practices"
  lesen: Wie frage ich & perlintro brian's Leitfaden für jedes Perl-Problem
  - +3 replies
  - Gast Muffi
    
    2012-06-01 17:06
    Auch ne Möglichkeit, muss ich mir noch durchdenken.
    
    Der komplette Aufbau schaut so aus, ich hab mir nen kleiner OR-Mapper geschrieben.
    
    main (alle Module Eigenbau)
    
    Code (perl): (dl )
    
    1 2 3
    
    use SQL; SQL::connect(); require User;
    
    Code (perl): (dl )
    
    1 2 3 4 5 6 7 8 9
    
    package User; use ORM; use base ORM; __PACKAGE__->ORM( fields => undef, # undef = autodetect primary => 'ID', table => User', )
    
    Code (perl): (dl )
    
    1 2 3 4 5 6 7 8 9 10 11
    
    package ORM; use SQL; sub ORM { ... for my $field (SQL::select(...)) { .... *$field_sub_name = sub { ...... } } }
    
    und der setzt dann dit getter und setter für die Felder.
    mit einem späteren ORM->init entstehen Funktionen in allen Klassen, die von ORM erben halt erst später.
    Last edited: 2012-06-01 17:07:52 +0200 (CEST)
    - +2 replies
    - pq
      
      2012-06-01 17:32
      
      User since
      2003-08-04
      12208 Artikel
      Admin1
      
      hm, ok, eigenes ORM... hab ich auch mal zeitweilig gemacht, weil mir DBIX::Class "verboten" war.
      will man eigentlich nicht machen, oder nur zum lernen, dass man lieber DBIx::Class oder was anderes fertiges benutzen will.
      
      aber schau dir doch zumindest ab, wie DBIx::Class das macht. da wird das auch erst zur laufzeit gemacht. sowieso sinnvoll, wenn man z.b. in einer webapp mit modperl oder fastcgi arbeitet, denn da muss sowieso ein db-handle pro prozess existieren.
      Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. -- Damian Conway in "Perl Best Practices"
      lesen: Wie frage ich & perlintro brian's Leitfaden für jedes Perl-Problem
      - Gast Muffi
        
        2012-06-01 21:30
        
        Ich mach das eigentlich aus 3 Gründen:
        - Soll auf Out-of-the-box-windows-perl laufen
        - Rumspielen
        - mal ein feature testen, das ich schon immer in sql vermisst habe
        
        momentan funktioniert schon sowas:
        
        Code (perl): (dl )
        
        say $_->title for User->find("self.adresse.plz = ? and self.account.active = 1", 12345)->mails->array
- +3 replies
- rosti
  
  2012-06-01 18:35
  User since
  2011-03-19
  3194 Artikel
  BenutzerIn
  Wenn die main kompliliert wird: Überall da wo use ... steht -> das wird zuerst kompiliert. Und ob der Perl-Interpreter beim Kompilieren dieselbe Reihenfolge nimmt, wie Du notiert hast, tja, das weiß ich auch nicht, auf jeden Fall würde ich mich nicht darauf verlassen.
  
  Anderer Vorschlag: Über eine mögliche Vererbung nachzudenken. Könnte so aussehen:
  
  Code (perl): (dl )
  
  1 2 3 4
  
  use MySQLModul; # Basisklasse für MySQL-Zeugs use NaechstesModul; # erbt von der Basiklasse my $instanz = NaechstesModul->new(%zugangsdaten);
  
  Wobei: use MySQLModul; wird dann nicht mehr in der main notiert sondern in dem Modul was erbt.
  
  Jetzt könntest Du noch in der Basisklasse eine Config-Datei einbinden, welche die Zugangsdaten auch ohne %zugangsdaten setzt (Default) und dafür sorgen, dass die Default-Zugangsdaten (z.B. Deine lokale DB) im Konstruktor der Subklasse überschrieben werden können (und sollten).
  
  Also: Abhängigkeiten zwischen Modulen durch Vererbung regeln.
  
  Nochwas zu use: Wenn Du notierst
  
  Code (perl): (dl )
  
  use Foo qw(bar);
  
  ist der String 'bar' das zweite Argument in der Methode 'import', die beim Kompilieren aufgerufen wird (das erste Argument ist der Klassenname).
  
  Mit require .. wird 'import' nicht aufgerufen. Evntl. könntest Du mit der 'import' Methode was anfangen...
  
  --Rosti
  
  PS/Edit: http://rolfrost.de/map/perlbase/dbi_enhanced.html
  Last edited: 2012-06-01 18:51:17 +0200 (CEST)
  - +2 replies
  - Gast Muffi
    
    2012-06-01 21:17
    
    Das mit dem Import hab ich auch mal kurz überlegt, aber ich glaube das ist eher Gegnerverwirrung ;)
    Last edited: 2012-06-01 21:23:43 +0200 (CEST)
    - rosti
      
      2012-06-01 21:44
      
      User since
      2011-03-19
      3194 Artikel
      BenutzerIn
      
      Guest Muffi
      Das mit dem Import hab ich auch mal kurz überlegt, aber ich glaube das ist eher Gegnerverwirrung ;)
      
      Straight ahead: http://www.youtube.com/watch?v=NcUrtzrax5g SCNR ;)
      
      Nutze die Vererbung! Alles Andere führt zum Chaos (hab letztes Jahr haufenweise solchen vermurksten Code nicht nur gesehen, sondern musste auch noch damit arbeiten).
      
      Grüße aus Rheinland Pfalz,
      Rosti

View all threads created 2012-06-01 16:33.