Die sind mir bei deinem Skript auch aufgefallen. Benutzt du kein Eclipse o.ä.? Da wurden mir sofort ein Haufen Zeilen als Gelb markiert (E_NOTICE), weil du die Variablen-Schreibweise manchmal gewechselt hast ($iproductId, $iProductId, ..).

Schon, aber nicht mehr PHPEclipse sondern PDT und das markiert mir nix mehr gelb -.- Kann man das irgendwo einstellen?

Zieh dir das Plugin, eclipse.org/php dann kannst du im Eclipse die Perspektive ändern.

Das hab ich ja (muss nochma Version checken), er macht auch, was er soll, bloss die gelben Kringellinien fehlen ^^ Ausnahmsweise funktioniert auch das Debuging, da hat sich PHPEclipse bei mir richtig gegen gewehrt

Am Wochenende setz ich mich dran - sorry fürs Verschleppen, aber hab grad kein Bock

So, hab Montag das letzte mal drauf geguckt und heute nochmal schnell und kurz ne neue Funktionalität eingeführt, dazu aber gleich noch was Der Link dazu ist der selbe geblieben: Datahandler/Csv.php

Ich würde es ja auch gerne selbst testen (vorallen da ich dann Fehler schnell selber beheben kann), aber mir fehlt ja nu weiterhin ne Project- und ne Work-Klasse, mit der ich was experimentieren kann, und da nen dummy selbst zu schreiben, bin ich zu faul Wär cool, wenn mir da jemand was zukommen lassen kann.

So, hab ja nu noch schnell was Neues eingebaut. Und zwar find ich es (entgegen bei Datenbanken) bei Csv-Dateien im Speziellen und Datenspeicherung in Dateien im Allgemeinen nicht sooo gelungen, wenn man nach 1 Jahr Dauerbetrieb 6 oder 7stellige IDs hat. Deshalb wird nun mit 1% Wahrscheinlichkeit (einstellbar zwischen 0.00 (nie) und 1.00 (immer)) die IDs der projekts und der works neu vergeben, wobei aber die Zuordnung der works zu den projects erhalten bleibt (solange alles funktioniert ). Die Wahrscheinlichkeit tritt erst dann ein, wenn sowieso auf die Dateien geschrieben wird (also wenn sich entweder die works oder die projects geändert haben). Ich hab diese Methode public gemacht, weiß aber noch nicht, ob das eine gute Idee war ^^

So, dann is erstmal für mich Pause

So jetzt. LOL hab grad gesehen, dein Skript hat ne Datei .DIRECTORY_SEPERATOR.project.csv im Document-Root angelegt

Kann die Csv.rar leider nicht runterladen.

Öhm ... das hab ich eigentlich korrigiert ^^ Is bei mir auch passiert Warum das immer noch da is, is mir unklar -.-

Joa, Server is grad irgendwie down, is dringend?

So tut mir Leid, habe das ganze etwas verschleppt. Hab nichtmal ne Ausrede
Habe mir jetzt die Datei von KingCrunch heruntergeladen, mal sehen was sich damit alles anstellen läßt.

So hihi jetzt der x-te Anlauf das ganze fertig zu bekommen. Muss sagen sehr schöner Quellcode KingCrunch, vorbildlich. So stell ich mir das vor. Noch 2 PHP-Notices aber das hat Eclipse gefixt

So. Das ganze klappt soweit leider nicht. Es sind zuviele Fehler in der Csv.php. Das liegt einfach an der Tatsache, dass du die Datei nicht getestet hast. Außerdem haben wir ein paar Schnittstellen-Probleme.

Zunächst hast du die write()-Methode hinzugefügt, die so nicht im Interface festgelegt war. Ich bin davon ausgegangen, dass beim Aufrufen einer set*() Funktion, das jeweilige Objekt sofort gespeichert wird. Wenn du nachträglich die Schnittstelle erweiterst musst du den Rest der Mannschaft davon informieren.
Weiterhin gab es noch erwähnte 2 Notices und file_put_content, hier fehlte ein s

Außerdem hat sich ein Fehler eingeschlichen, den wir nicht bedacht hatten (oder hast du es?) Und zwar darf sich die ID eines Elements niemals ändern. Außerdem ist bei setProject() die ID möglicherweise noch garnicht gesetzt (wenn ich nämlich ein neues Projekt anlege). Deine Klasse muss dem Element dann seine ID zuweisen.

Optimal wäre es, wenn wir noch 2 Erweiterungen einführen könnten:
set*() Methoden haben als Rückgabewert nicht BOOL, sondern ihr gespeichertes Objekt. Also nicht das übergebene Objekt, sondern die set*() Methode muss dann nach dem Speichern mit der get*() Methode das Objekt abrufen. Somit kann das Anwender-Skript gleich sehen, ob die Speicherung auch erfolgreich war (und die erfolgreich abgespeicherten Daten zB gleich wieder ins Formular eintragen - somit bekommt auch der Anwender mit, ob die Speicherung erfolgreich war).

Außerdem habe ich deinen Konstruktor bearbeitet. Es macht keinen Sinn einen Dateinamen zu übergeben, wenn die Speicherung auf mehreren Dateien vorgenommen wird. Somit wird nun ein Pfad als Wert erwartet/übergeben.

Somit ergibt sich folgende Schnittstelle (falls du noch Lust hast KingCrunch )
So schön kann Teamarbeit sein. Tja da sieht man mal was alles schief gehen kann, obwohl man glaubt alles weitestgehend sauber geplant zu haben

write() sollte demnach weg, wenns geht

Öhm ... write() war doch protected und nur vom destructor aufgerufen. Insofern beinträchtigt es die Schnittstelle doch nicht ^^ Und da zur Laufzeit die Daten nicht aus der Datei, sondern aus dem ... ah, ich glaub, ich seh das Problem ^^ Wenn man zwei Objekte in der Art hat gleichzeitig hat so von wegen Synchronität Hätte eigentlich gerne die write-Methode behalten und Lese-/Schreibzugriffe zu minimieren, vielleicht denk ich mir da was mit Options aus (Dann default eben off ) Das beudetet dummerweise aber auch, dass ich bei jeden Lese-Zugriff auch immer die Datei lesen muss, weil ein anderes Objekt sie ja geändert haben muss -.- Nagut, bin jetzt (mutwillig) davon ausgegangen, dass zeitgleich immer nur ein Objekt der Art existiert ^^

Ah, ne, hab write public gemacht, falls mal jemand so nebenbei speichern will ^^ Also nicht als Interface-Erweiterung, sondern als interne Funktion mit "feature", dass man sie auch von aussen (gefahrlos ^^) ausführen kann. Wirdse einfach protected gemacht und bei jedem Set aufgerufen, das sollte klappen.

Das mit set sinngemäß so, oder?
Das mit dem Dateinamen hab ich 3 mal (oder so) angesprochen, da hieß es nur: Denk dir was aus Hab ich Dateipfad is aber wirklich besser, stimmt scho.

Das mit der ID hab ich auch lange überlegt, andererseits habe ich mir gedacht: Die ID kann sich erst im Destructor ändern, was bedeutet, dass es kein X-Objekt mit der id mehr geben sollte. Also macht es sich erst (intern) beim nächsten Aufruf bemerkbar, wobei dann alle gleichartigen Objekte wiederum die selbe ID besitzen. Und solang die Bezüge bestehen bleiben ... Andererseits gehn mir auch die Gegenargumente durch den Kopf ^^ Nicht drüber nachdenken Fürn Workaround kann man das "id-reset" erstmal auf 0.00 stellen, solange bis es wieder raus kommt. Wobei ich dieses "feature" auch hier angekündigt habe


Sind aber ehrlich gesagt auch net sooo die umfangreicheren Änderungen ^^ (Will, dass mir PDT wieder die Notices markiert -.-) Ich gucks mir ma an.


PS: remove*() geben aber weiterhin bool aus?

Ja soweit alle Aussagen korrekt

Ich hätte auch noch sowas anzubieten
Da wären wir wieder bei Bool und man kann sich sicher sein, dass der Rückgabewert nicht nur geschätzt ist ^^

Eigentlich interessiert uns ja nicht nur ob die Speicherung geklappt hat, sondern was ihr Ergebnis ist. Es könnte ja sein, dass die Speicherung teilweise geklappt hat, zum Beispiel alles abgespeichert wurde, nur der Name zuviel Zeichen hatte und deshalb abgeschnitten wurde. Wäre das dann ein TRUE oder FALSE?
Das sollte die Anwendung im Einzelfall entscheiden.

(wenn ich an allem was rumzunörgeln hab, dann heißt das nicht dass das Sinn macht, ich denke nur laut und kritisieren ist besser als alles gut finden - also sagt ruhig eure Meinung dazu)