Ankündigung

Einklappen
Keine Ankündigung bisher.

csv Zeile enthält die Namen der Variable die verarbeitet werden sollen -> GELÖST

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • #16
    Ist angekommen, Danke

    Kommentar


    • #17
      Die Aufgabe hier kann auch so etwas allgemeiner formuliert werden:

      1. Eine CSV-Datei einlesen
      2. Die Daten in ein mehrdimensionales Array packen
      3. Die erste Zeile der CSV-Datei als Schlüssel/Spaltennamen nutzen
      4. Alle Zeilen rausfiltern die in einer Spalte einen bestimmten Suchbegriff enthalten

      Dafür möchte ich eine alternative Lösung auf der Basis von PHP-Klassen zeigen.

      PHP-Code:
      $csv = new SplFileObject('datei.csv');

      $csv->setFlags(SplFileObject::READ_CSV 
        
      SplFileObject::SKIP_EMPTY 
        
      SplFileObject::READ_AHEAD 
        
      SplFileObject::DROP_NEW_LINE
      );
      $csv->setCsvControl(","); 
      Mit $csv steht jetzt ein Objekt zur Verfügung, über das im einfachsten Fall mit foreach iteriert werden kann oder wie hier an eine weitere Klasse übergeben wird:
      PHP-Code:
      $tabArr = new tableArray($csv); 
      Punkt 1 und 2 der obigen Aufgabe sind damit bereits erledigt.
      Der Suchbegriff soll sich in der ersten Spalte befinden. Für das Filtern entsprechend Punkt 4 muss der Spaltenname zuvor ermittelt werden. Danach kann die erste Zeile zu Schlüsseln gemacht werden (firstRowToKey() ), die Zeilen gefiltert (filterLikeIn() ) und geliefert werden (fetchAll() ).
      PHP-Code:
      $firstFieldName $tabArr->fetchColumn(0)[0];
      $search 'findthis';

      $foundRows $tabArr
        
      ->firstRowToKey()
        ->
      filterLikeIn($firstFieldName,$search)  
        ->
      fetchAll()

      Nun werden einige Leser denken soviel kürzer ist das auch nicht und dafür extra Klassen nutzen?
      Die Vorteile einer solchen Lösung kommen neben einer besseren Lesbarkeit erst richtig zum Tragen wenn die Aufgabe komplizierter wird. Wenn als Beispiel mehrere Suchbegriffe vorliegen können diese als Liste/Array für $search übergeben werden. Oder wenn die Fundstellen mit einer speziellen Sortierung geliefert werden sollen muss nur eine Zeile mit einem ->orderBy(..) eingefügt werden.

      (Die Klasse SplFileObject ist praktisch mit jeder PHP-Installation vorhanden und tableArray ist auf GitHub verfügbar)


      Kommentar


      • #18
        Ich finde ja, wenn du schon deine Klassen immer wieder unterschwellig Promotest, sollten sie wenigsten den PSR Regeln folgen, wie CamelCase für Klassen Namen, vernünftige Versionierung mit Git Tags, sowie in einem eigenen Namespace sein. Außerdem eine composer.json bereit stellen, so dass man sie auch einfach verwenden kann.

        Nimm das bitte nicht als negative Kritik, sondern als Konstruktive.

        Kommentar


        • #19
          Die Kritik ist nicht ganz neu. Ich gebe zu Bedenken das der Beitrag hier sowie die Klassen Einsteiger als Zielgruppe haben und keine Profis. Profis nutzen vorzugsweise große Frameworks die mit ihren Komponenten mindestens Gleichwertiges bieten und in meinen Augen keine Veranlassung haben, eine solche Klasse wie tableArray zu nutzen. Kann sein das ich dies falsch sehe, zähle mich nicht zu den Profis.
          Für Einsteiger ist m.E. auch der Zwang Composer zu benutzen, der ja wieder eine Reihe von Regeln und Restriktionen die zu befolgen sind nach sich zieht, eher eine Hemmschwelle zum Erlernen von Techniken der objektorientierten Programmierung. Die angepriesenen Klassen sind inbesondere für Einsteiger bequem zu nutzen da diese alle keine weiteren Ressourcen/Pakete benötigen, dem Prinzip "eine Klasse = eine Datei" folgen und es mit einem Download dieser einen Datei eine einfache Verwendung ermöglicht wird. Der Nutzer hat so vor den Augen was er da einbindet. Bei der Nutzung von Composer ist das nicht gegeben.
          Kritisch sehe ich auch einige PSR-Regeln und alles was mit Namespaces zu tun hat. Namespaces halte ich für eine elende Krücke die benötigt wird wenn es zu Namenskonflikten bei Klassen kommt. Diese Namenskonflikte werden gefördert durch den für mich unverständlichen Drang vieler Programmierer eine Klasse in Hunderte Subklassen/Dateien zu zerstückeln um maximale Flexibilität vorzutäuschen. Ich selber habe in meinen Projekten mit wenigen Ausnahmen (Fremdcode) bisher keine Namespaces benötigt.

          Kommentar


          • #20
            Namespaces werden ja auch dazu verwendet den globalen Namensraum freizuhalten. Als Beispiel mal: Bis PHP 5.5 gab es kein DateTimeInterface, viele Entwickler haben sich ein eigenes Interface mit diesem Namen angelegt. Als dies dann mit php 5.5 eingeführt worden ist, hagelt es plötzlich Fehlermeldungen weil das Interface bereits existiert. Hätte man das Interface nun in seinem eigenen App Namespace gehabt und nicht im Globalen, dann hätte es dieses Problem nicht gegeben.

            Das Aufteilen einer Klasse in Teilprobleme, hat eigentlich weniger damit zu tun Flexibilität vorzutäuschen, sondern dem Leitspruch zu folgen: Eine Klasse => Eine Aufgabe. Ich kann also die Teilkomponenten einer Klasse einzeln Testen und auch warten.

            Zu Composer:
            Dies wäre ja immer noch optional und kein muss, es fördert aber die einfache Verwendung deiner Klasse. Es steht ja jedem weiter frei, die Datei per Hand runterzuladen.

            Kommentar


            • #21
              Zitat von Zeichen32 Beitrag anzeigen
              Namespaces werden ja auch dazu verwendet den globalen Namensraum freizuhalten.
              Freihalten für was und wen? Ich als Einzelkämpfer nutze selbstverständlich den globalen Namensraum und darf nur nicht den Überblick verlieren. Ich weis aber wie du das meinst.
              Kann mir auch vorstellen das bei großen Projekten an denen ein ganzes Team arbeitet andere Regeln gelten.

              Zitat von Zeichen32 Beitrag anzeigen
              Als Beispiel mal: Bis PHP 5.5 gab es kein DateTimeInterface, viele Entwickler haben sich ein eigenes Interface mit diesem Namen angelegt. Als dies dann mit php 5.5 eingeführt worden ist, hagelt es plötzlich Fehlermeldungen weil das Interface bereits existiert. Hätte man das Interface nun in seinem eigenen App Namespace gehabt und nicht im Globalen, dann hätte es dieses Problem nicht gegeben.
              Ein Interface mit Namespace für Klassen die im globalen Namensraum und im Kern von PHP verankert sind ?
              Mir ist es bei einen solchen Fall sogar lieber mir fliegt eine Fehlermeldung mit einer klaren Ansage um die Ohren. Den kann ich dann ordentlich beseitigen. Finde ich besser als wenn die Applikation mit einen veralteten eigenen Interface weiter werkelt. Das nur am Rande.

              Zitat von Zeichen32 Beitrag anzeigen
              Das Aufteilen einer Klasse in Teilprobleme, hat eigentlich weniger damit zu tun Flexibilität vorzutäuschen, sondern dem Leitspruch zu folgen: Eine Klasse => Eine Aufgabe. Ich kann also die Teilkomponenten einer Klasse einzeln Testen und auch warten.
              Ich habe nichts gegen eine sinnvolle Aufteilung in Teilprobleme. Man kann es jedoch auch übertreiben. Wenn ich da eine Unzahl Klassen sehe, die alle nur aus einer Methode und den Konstruktor bestehen oder gar nur 3 Konstanten enthalten da hört für mich die sinnvolle Aufteilung von Aufgaben auf.

              Zitat von Zeichen32 Beitrag anzeigen
              Zu Composer:
              Dies wäre ja immer noch optional und kein muss, es fördert aber die einfache Verwendung deiner Klasse. Es steht ja jedem weiter frei, die Datei per Hand runterzuladen.
              Um die Klasse für einen Bezug durch den Composer fit zu machen reicht es ja nicht eine composer.json bereitzustellen. Da sind ja eine Reihe von Regeln einzuhalten, PSR damit der Autoloader dann funktioniert und die Verwendung von Namespaces sind nur zwei Punkte davon. Genau da habe ich immer noch Zweifel, ob dies die einfache Verwendung der Klasse fördert oder eher die Zielgruppe Einsteiger/Hobbyprogrammierer abschreckt.
              Dazu kommt das ich selbst Composer nicht benutze/brauche.

              Oder mal anders herum die Frage an die Composernutzer hier:
              Ist es überhaut noch mit wenig Aufwand machbar eine Klasse einzubinden die nicht per Composer bezogen werden kann?

              Kommentar


              • #22
                Zitat von jspit Beitrag anzeigen
                Freihalten für was und wen?
                Für PHP bzw. PHP-Module. Nachdem es in PHP nicht wie in vielen anderen Sprachen einen System-Namespace gibt, ist der globale Namespace als System-Namespace anzusehen. Und da sollte nicht reingepfuscht werden.

                Kommentar


                • #23
                  Zitat von jspit Beitrag anzeigen
                  Dazu kommt das ich selbst Composer nicht benutze/brauche.

                  Oder mal anders herum die Frage an die Composernutzer hier:
                  Ist es überhaut noch mit wenig Aufwand machbar eine Klasse einzubinden die nicht per Composer bezogen werden kann?
                  Du handelst also komplett nach der "Ich will das selbst schaffen"-Attitüde oder wie bindest du Pakete bei dir ein und löst deren Abhängigkeiten auf?

                  Wenn ich jetzt deine Klasse in eine größere (ZF3)-Anwendung von uns einbinden müsste, würde ich dieser einen Autoloader-Namespace meiner App verpassen.
                  Das ist soweit kein Problem, aber über Composer sicher einfacher. Vor Allem, weil ich diese dann auch automatisch aktualisieren kann und nicht ins Repo einchecken muss.
                  sorry, shift-taste kaputt

                  Kommentar


                  • #24
                    Zitat von hellbringer Beitrag anzeigen
                    Für PHP bzw. PHP-Module. Nachdem es in PHP nicht wie in vielen anderen Sprachen einen System-Namespace gibt, ist der globale Namespace als System-Namespace anzusehen. Und da sollte nicht reingepfuscht werden.
                    Extremer Standpunkt, aber in gewisser Weise konsequent.

                    Zitat von Meister1900 Beitrag anzeigen
                    Du handelst also komplett nach der "Ich will das selbst schaffen"-Attitüde oder wie bindest du Pakete bei dir ein und löst deren Abhängigkeiten auf?
                    Ja, im Grunde schon. Meine Projekte sind von wenigen Hobbyanwendungen mal abgesehen jedoch nicht mit herkömmlichen Webanwendungen vergleichbar. Große Pakete und Framworkkomponenten einzubinden fällt dort komplett aus. In den Anwendungen sind daher 99% der Codezeilen selbst geschrieben. Alles "Ein-Mann-Projekte". Das betrifft auch einige Hilfsmittel wie z.B. eine eigene Testumgebung, wo viele PHPUnit nutzen. Ich entwickle da gewissermaßen in einer Parallelwelt jedoch mit Einblick in die echte Welt.

                    Zitat von Meister1900 Beitrag anzeigen
                    Wenn ich jetzt deine Klasse in eine größere (ZF3)-Anwendung von uns einbinden müsste, würde ich dieser einen Autoloader-Namespace meiner App verpassen.
                    Das ist soweit kein Problem, aber über Composer sicher einfacher. Vor Allem, weil ich diese dann auch automatisch aktualisieren kann und nicht ins Repo einchecken muss.
                    Danke, das beantwortet meine Frage.

                    Kommentar

                    Lädt...
                    X