[1.16] tools/filesystem

Dieser Bereich dient dazu, neue Features zu diskutieren und für die Entwicklung zu dokumentieren. // This area is dedicated to new features including proposals and documentation.
TipTop
Beiträge: 193
Registriert: 25.08.2011, 22:37:08
Wohnort: Klagenfurt, Österreich
Kontaktdaten:

[1.16] tools/filesystem

Beitrag von TipTop » 29.04.2012, 20:05:01

Hi,

könnte man den Filesystem-Manager für 1.16 erweitern? Ich denke dabei generell an eine Abstrahierung aller wichtigen Datei- und Verzeichnis Funktionen. Zudem sollten Verzeichnisse und Dateien durch Domain-Objects repräsentiert werden, sodass alles schön objekt orientiert abläuft.

Auf der Roadmap für 1.16 wurde ja bereits erwähnt, dass der Filesystemmanager erweitert werden soll - abgesehen von den bereits geplanten Erweiterungen, würde ich noch folgende Methoden vorschlagen (bzw. die bereits vorhandenen folgendermaßen abändern):

saveFile(File $file)
saveDirectory(Directory $dir)
getFile($path)
getDirectory($path, $getChildren = false, $maxDepth = false)
renameFile(File $file, $newName, $force = false)
renameDirectory(Directory $dir, $newName, $force = false)
copyFile(File $file, $targetBasePath)
copyDirectory(Directory $dir, $targetBasePath)
deleteFile(File $file)
deleteDirectory(Directory $dir)
uploadFile($dir, $temp_file, $file_name, $file_size, $file_max_size, $file_type, $allowed_mime_types)
downloadFile(File $file)


Ich denke, die Methodennamen und Parameter sind selbsterklärend. Vielleicht noch kurz etwas zu saveFile() und saveDirectory():
Diese Methoden arbeiten wie die Methode saveObject() des GORMs - übergibt man also ein Verzeichnis bzw. eine Datei, die noch nicht existiert, wird diese erstellt. Existiert die Datei bzw. das Verzeichnis bereits, wird dieses geupdatet - geupdatet werden alle im DomainObject erhältlichen Attribute, die nicht null sind.


Das DomainObject File könnte über folgende Attribute verfügen:

- name
- basePath
- content
- mimeType
- size
- lastAccessTime
- lastModificationTime
- owner
- type
- permissons

Für jedes Attribut existiert natürlich eine set- und get-Methode. Für das Attribut content gibt es noch die Methoden prependContent() und appendContent(), um Inhalte vor bzw. nach dem orginal Inhalt hinzuzufügen.

Das Directory-DomainObject wäre von den Attributen her relativ ähnlich. Anstatt dem content-Attribut verfügt es aber über das Attribut children (Array), in welchem Dateien und Verzeichnisse (also wieder DomainObjects) gespeichert werden (können).

Die Methode FilesystemManager::getDirectory() kann einen Dateibaum kreieren - dazu setzt man den 2. Parameter (getChildren) auf true. Mit dem 3. Parameter lässt sich die maximale Tiefe des Datei-Baumes festlegen. Mit Directory::getChildren() erhält man dann ein Array, welches die Kinddateien und -verzeichnisse beinhaltet.



Was haltet Ihr davon?

Grüße
Nico

Benutzeravatar
dr.e.
Administrator
Beiträge: 4555
Registriert: 04.11.2007, 16:13:53

Re: [1.16] tools/filesystem

Beitrag von dr.e. » 29.04.2012, 21:07:24

Hallo Nico,

ich halte die/das Erweiterung/Refactoring für absolut sinnvoll und konsequent. Aktuell ist das Interface etwas dürftig und noch nicht besonders vom OO-Stil geprägt. Wenn du magst, kannst du die Erweiterung implementieren und wir diskutieren die Anwendung zusammen.
Zudem sollten Verzeichnisse und Dateien durch Domain-Objects repräsentiert werden, sodass alles schön objekt orientiert abläuft.
Sofern alles korrekt OO-konform implementiert werden soll, dürfte es keinen Manager in dem heutigen Sinne mehr geben, da sich alles durch File und Directoryabstrahieren ließe. Dabei erbt Directory von vermutlich File.
Diese Methoden arbeiten wie die Methode saveObject() des GORMs - übergibt man also ein Verzeichnis bzw. eine Datei, die noch nicht existiert, wird diese erstellt. Existiert die Datei bzw. das Verzeichnis bereits, wird dieses geupdatet - geupdatet werden alle im DomainObject erhältlichen Attribute, die nicht null sind.
Das kommt auf den Anwendungsfall an. Bei einigen möchtest du verhindern, dass eine Datei in ein bereits existierendes Verzeichnis legst, da das eine Kollision bedeuten könnte. Hier sollten wir vielleicht einen strict-/lax-Mode einführen, der es entweder krachen lässt wenn notwendig oder milde darüber hinweg sieht. Ich denke bei dieser Anwendung vor allem an das Thema Cache.
Für das Attribut content gibt es noch die Methoden prependContent() und appendContent(), um Inhalte vor bzw. nach dem orginal Inhalt hinzuzufügen.
Gute Idee. Bei der Implementierung sollten wir jedoch auf gute Performance achten, sonst ist das für Logfiles nicht wirklich nutzbar.
Die Methode FilesystemManager::getDirectory() kann einen Dateibaum kreieren - dazu setzt man den 2. Parameter (getChildren) auf true. Mit dem 3. Parameter lässt sich die maximale Tiefe des Datei-Baumes festlegen. Mit Directory::getChildren() erhält man dann ein Array, welches die Kinddateien und -verzeichnisse beinhaltet.
Wenn Directory schon ein Domain Object ist, würde ich ich im getChildren() jeweils lazy den weiteren Baum aufbauen, wenn noch nicht gefüllt. So bist du garnicht erst gezwungen mit derartigen Parametern zu arbeiten, sondern die Anwendung des Objektes bestimmt jeweils die Tiefe des Baumes. So entstehen keine unnötige Zugriffe.

Nachdem 1.15-stable noch etwas braucht (UMGT-Doku ist doch aufwendiger als erwartet), könnten wir das auch in 1.15 einbauen. Voraussetzung ist, dass eine Doku vorliegt (siehe GORM-Erweiterung).
Viele Grüße,
Christian

TipTop
Beiträge: 193
Registriert: 25.08.2011, 22:37:08
Wohnort: Klagenfurt, Österreich
Kontaktdaten:

Re: [1.16] tools/filesystem

Beitrag von TipTop » 29.04.2012, 22:31:49

Nachdem 1.15-stable noch etwas braucht (UMGT-Doku ist doch aufwendiger als erwartet), könnten wir das auch in 1.15 einbauen.
Gut, dann kümmer ich mich drum.

Dabei erbt Directory von vermutlich File.
Ich persönlich würde die beiden Objekte nicht in eine Vater-Kind-Beziehung stellen - auf manchen OS's zählt man Verzeichnisse zwar zu Dateien, auf anderen aber auch wieder nicht.

Directory würde jedenfalls über Funktionalität verfügen, mit der es nichts anfangen kann (bspw. setContent(), appendContent(), prependContent(), mimeType). Wie wärs stattdessen mit einer FilesystemItem-Klasse, die als Vaterklasse für File und Directory dient und in der man die Gemeinsamkeiten von Dateien und Verzeichnissen definiert (vergleichbar mit core/database/abstractDatabaseHandler.php).

Bei der Implementierung sollten wir jedoch auf gute Performance achten, sonst ist das für Logfiles nicht wirklich nutzbar.
Bei new File('pfad/zu/einer/datei.php'); wird mittels fopen() ein FileHandle angefordert und im DomainObject gespeichert. Die Methoden setContent(), appendContent() und prependContent() nutzen dieses FileHandle und würden dann ja nur noch fwrite() nutzen - das wäre dann ja nicht so performancelastig, oder?
Wenn Directory schon ein Domain Object ist, würde ich ich im getChildren() jeweils lazy den weiteren Baum aufbauen, wenn noch nicht gefüllt.
Ja, gute idee :)



Voraussetzung ist, dass eine Doku vorliegt (siehe GORM-Erweiterung).
Hast Du dir den Code zum Tree-Feature bereits angesehen? Ich dachte ich warte mit der Doku noch, falls noch gröbere Änderungen anfallen.




Grüße
Nico

Megger
Beiträge: 1233
Registriert: 04.11.2008, 10:57:37

Re: [1.16] tools/filesystem

Beitrag von Megger » 29.04.2012, 22:45:31

Eine flock Unterstützung fände ich auch noch sinnvoll
Tutorial: Browsergame mit dem APF (Die ersten Parts handeln von Installation und Inbetriebnahme des APFs, deswegen sicherlich auch für alle Nicht-Browsergame-Programmierer interessant)

APF-Version
  • Entwicklung: 2.0
  • Produktiv: 1.15

TipTop
Beiträge: 193
Registriert: 25.08.2011, 22:37:08
Wohnort: Klagenfurt, Österreich
Kontaktdaten:

Re: [1.16] tools/filesystem

Beitrag von TipTop » 01.05.2012, 12:08:47

Hier mal ein Grundgerüst wie das aussehen könnte: http://www.nicolas-pecher.com/filesystem.zip

Wie siehts mit Exceptions aus? Sollen welche geworfen werden, oder soll immer nur ein Boolean zurückgegeben werden?


Grüße
Nico

TipTop
Beiträge: 193
Registriert: 25.08.2011, 22:37:08
Wohnort: Klagenfurt, Österreich
Kontaktdaten:

Re: [1.16] tools/filesystem

Beitrag von TipTop » 01.05.2012, 15:31:03

So, Funktionalität ist nun auch vorhanden: http://www.nicolas-pecher.com/filesystem.zip

Benutzeravatar
dr.e.
Administrator
Beiträge: 4555
Registriert: 04.11.2007, 16:13:53

Re: [1.16] tools/filesystem

Beitrag von dr.e. » 02.05.2012, 10:49:21

Hallo Nico,

danke für das ZIP. Habe den Code grob überflogen und ein paar Punkte gefunden. Poste noch ein ausführliches Review.

Vorab: hast du mal versucht, die bisherigen Anwendungsfälle des FilesystemManager mit dem neuen Ansatz durchzuspielen?
Viele Grüße,
Christian

TipTop
Beiträge: 193
Registriert: 25.08.2011, 22:37:08
Wohnort: Klagenfurt, Österreich
Kontaktdaten:

Re: [1.16] tools/filesystem

Beitrag von TipTop » 02.05.2012, 14:37:10

Hi,
Vorab: hast du mal versucht, die bisherigen Anwendungsfälle des FilesystemManager mit dem neuen Ansatz durchzuspielen?
Nein, zum Testen bin ich leider noch nicht gekommen - werde mich aber heute noch drum kümmern.


Edit:
Kleine Änderung: Die Methode getParent(), die das übergeordnete Verzeichnis (in Form eines Directory-Objects) zurückliefert habe ich von der Klasse Directory in FilesystemItem verschoben und heißt nun getParentDirectory().

Benutzeravatar
dr.e.
Administrator
Beiträge: 4555
Registriert: 04.11.2007, 16:13:53

Re: [1.16] tools/filesystem

Beitrag von dr.e. » 02.05.2012, 22:01:04

OK, dann warte ich mal auf deinen Test. Ich nehme mir auf jeden Fall auch nochmal die Zeit um die Implementierung meiner Projekte dagegen zu checken.

Thanks so far! :)
Viele Grüße,
Christian

Benutzeravatar
dr.e.
Administrator
Beiträge: 4555
Registriert: 04.11.2007, 16:13:53

Re: [1.16] tools/filesystem

Beitrag von dr.e. » 25.05.2012, 23:01:57

Hallo Nico,

gibt es schon etwas neues in dieser Sache?
Viele Grüße,
Christian

TipTop
Beiträge: 193
Registriert: 25.08.2011, 22:37:08
Wohnort: Klagenfurt, Österreich
Kontaktdaten:

Re: [1.16] tools/filesystem

Beitrag von TipTop » 26.05.2012, 14:01:33

Hi,

beim testen ist mir gerade aufgefallen, dass der Klassenname Directory ja bereits von PHP "reserviert" ist - in was sollte ich die Klasse umbennen?

Benutzeravatar
dr.e.
Administrator
Beiträge: 4555
Registriert: 04.11.2007, 16:13:53

Re: [1.16] tools/filesystem

Beitrag von dr.e. » 26.05.2012, 23:40:05

Hi,

ich würde entweder ein APFDirectory draus machen oder sie Folder nennen. Letzteres ist meiner Ansicht nach griffiger.
Viele Grüße,
Christian

Benutzeravatar
dave
Beiträge: 903
Registriert: 04.02.2011, 19:03:57
Wohnort: Berlin
Kontaktdaten:

Re: [1.16] tools/filesystem

Beitrag von dave » 18.07.2012, 17:04:45

Habe Nice mal eine PN zwecks Stand geschrieben und mit diesem Post ist das jau auch wieder hervorgehoben.

Nico, wie siehts aus? :)

TipTop
Beiträge: 193
Registriert: 25.08.2011, 22:37:08
Wohnort: Klagenfurt, Österreich
Kontaktdaten:

Re: [1.16] tools/filesystem

Beitrag von TipTop » 18.07.2012, 17:43:49

Hi dave,

hier der letzte Stand: http://www.webrex.org/filesystem.zip

Von der Funktionalität sollte es soweit fertig sein, allerdings noch alles ungetestet.

Benutzeravatar
dave
Beiträge: 903
Registriert: 04.02.2011, 19:03:57
Wohnort: Berlin
Kontaktdaten:

Re: [1.16] tools/filesystem

Beitrag von dave » 18.07.2012, 18:27:53

Das ging aber fix!

Habe es bereits herunter geladen. Werde mir das mal in Ruhe morgen ansehen. Feedback gibts dann genau hier.

Gesperrt

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 2 Gäste