Ist angekommen, Danke
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
-
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(",");
PHP-Code:$tabArr = new tableArray($csv);
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()
;
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
-
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
-
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
-
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
-
Zitat von Zeichen32 Beitrag anzeigenNamespaces werden ja auch dazu verwendet den globalen Namensraum freizuhalten.
Kann mir auch vorstellen das bei großen Projekten an denen ein ganzes Team arbeitet andere Regeln gelten.
Zitat von Zeichen32 Beitrag anzeigenAls 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.
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 anzeigenDas 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.
Zitat von Zeichen32 Beitrag anzeigenZu 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.
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
-
Zuletzt geändert von hellbringer; 29.11.2018, 23:13.Zitat von jspit Beitrag anzeigenFreihalten für was und wen?
Kommentar
-
Zitat von jspit Beitrag anzeigenDazu 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?
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
-
Zitat von hellbringer Beitrag anzeigenFü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.
Zitat von Meister1900 Beitrag anzeigenDu 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?
Zitat von Meister1900 Beitrag anzeigenWenn 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.
Kommentar
Kommentar