[PHP5.1] LISTING D'UN RÉPERTOIRE AVEC FILTRES
Utilisateur anonyme
-
22 déc. 2007 à 20:21
neigedhiver Messages postés 2480 Date d'inscription jeudi 30 novembre 2006 Statut Membre Dernière intervention 14 janvier 2011 - 28 sept. 2010 à 12:27
neigedhiver Messages postés 2480 Date d'inscription jeudi 30 novembre 2006 Statut Membre Dernière intervention 14 janvier 2011 - 28 sept. 2010 à 12:27
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/45125-php5-1-listing-d-un-repertoire-avec-filtres
https://codes-sources.commentcamarche.net/source/45125-php5-1-listing-d-un-repertoire-avec-filtres
28 sept. 2010 à 12:27
C'est pourtant simple...
Il faut inclure le fichier init_xdir.php en spécifiant son chemin
* # Inclusion des fichiers nécessaires, définitions des classes, et tout le tremblement
* require_once('/path/to/xdir/init_xdir.php');
On instancie l'itérateur en passant en argument le chemin du répertoire à parcourir (absolu de préférence)
* # Notre itérateur
* $oDir = new XDir('/home/user/docs');
On applique des filtres (cf la doc fournie dans le zip)
* # Ne lister que les fichiers modifiés depuis une semaine
* $oDir -> addFilter('mtime', strtotime('-1 week'));
On boucle sur l'itérateur pour afficher le contenu. Sachant que l'itérateur renvoit pour chaque fichier, un objet qui étend splFileInfo (qui hérite donc de ses méthodes et propriétés et en apporte quelques une en plus).
* # On boucle
* foreach ($oDir as $oFile) {
* echo $oFile -> getFilename() . '
'; //
* }
C'est tout.
Et ça, c'est ce qu'il y a en exemple sur cette page...
28 sept. 2010 à 11:25
16 sept. 2010 à 13:25
De par son fonctionnement, cette classe ne permet pas de trier les fichiers : l'itérateur permet de parcourir les fichiers tels qu'ils viennent...
Pour povoir trier, il faudrait encapsuler la classe dans un autre itérateur qui récupèrerait d'abord (dans le constructeur) tous les fichiers, qui les trierait et les afficherait ensuite (lors de l'itération). Ce n'est pas vraiment un fonctionnement optimal en terme de performances, même si c'est plus 'pratique".
16 sept. 2010 à 11:46
Merci pour cet excellent script.
Question : comment ordonner les fichiers affichés (par nom, date de dernière modification, taille etc.) ?
Merci d'avance pour votre réponse.
12 févr. 2010 à 10:11
Je viens de tomber sur une limitation : j'ai voulu utiliser xdir pour supprimer un dossier et son contenu (suppression effectuée avec une classe maison, un équivalent de "rm -r")
Voilà mon code :
$oDir = new XDir($personne->getCheminDossier ());
$oDir->addFilter ('dir', TRUE);
$oDir->addFilter('regex', $personne->getCode ());
foreach ($oDir as $oFile) {
serveur::supprimer ($oFile->getPathname ()); /* suppression du dossier et de son contenu */
}
En fait, cela ne peut pas fonctionner puisque le foreach instancie avec un chemin qui n'existe plus : le dossier a été supprimé entre temps...
Bon usage de l'information !
15 janv. 2010 à 13:59
Merci pour le retour. Il y a effecivement un bug avec les filtres sur dates. J'ai commencé à regarder, mais j'ai plusieurs manières de corriger et je ne sais pas encore laquelle choisir.
Pour les permissions sur les fichiers, ce n'est effectivement pas géré. Je ne m'étais pas encore posé la question... Normalement, la gestion des erreurs n'est pas du ressort de la classe, mais de l'utilisateur. Ce n'est donc pas réellement un bug. J'ai conscience, cependant, que l'exception n'est pas facile à gérer à cause de la boucle foreach... Je vais donc ajouter une option pour permettre d'ignorer le contenu des répertoires dont on n'a pas la permission d'accéder au contenu.
Mise à jour prévue... quand mon PC sera réinstallé et pleinement opérationnel.
15 janv. 2010 à 01:40
je viens de faire une pair de tests et il y a quelques beugs : notamment dans la gestion des exceptions genre pas de droits d'accès à un répertoire enfant :
Fatal error: Uncaught exception 'UnexpectedValueException' with message 'RecursiveDirectoryIterator::__construct(/Users/joan/.cups) [recursivedirectoryiterator.--construct]: failed to open dir: Permission denied' in /Library/WebServer/Documents/xdir-1.1.4/init_xdir.php:18 Stack trace: #0 [internal function]: RecursiveDirectoryIterator->__construct('/Users/joan/.cu...', 0) #1 [internal function]: RecursiveDirectoryIterator->getChildren() #2 /Library/WebServer/Documents/xdir-1.1.4/init_xdir.php(18): FilterIterator->next() #3 {main} thrown in /Library/WebServer/Documents/xdir-1.1.4/init_xdir.php on line 18
et je tente d'appliquer un filtre : ($oDir -> addFilter('mtime', strtotime('-1 week'));)
Warning: ReflectionObject::__construct() expects parameter 1 to be object, null given in /Library/WebServer/Documents/xdir-1.1.4/libs/filters/time.abstract.filter.php on line 28
Fatal error: Internal error: Failed to retrieve the reflection object in /Library/WebServer/Documents/xdir-1.1.4/libs/filters/time.abstract.filter.php on line 29
1 déc. 2009 à 01:25
Le bug a été corrigée et un autre identifié (et corrigé dans la foulée).
29 nov. 2009 à 00:04
Wind
28 nov. 2009 à 21:36
Je regarde ça pour corriger cette horreur/erreur... Parce que du coup, sans récursivité, on ne peut pas filtrer, et c'est pas glop...
28 nov. 2009 à 19:12
je comprend trop comment accéder à $oFile -> getExtension(); dans une boucle while quant on crée un nouvel itérateur non récursif $oDir = new XDir('/home/user/docs', false); en récursif ca marche sinon il ne trouve pas la méthode, visiblement il faut passer par $oFile -> getFileInfo() -> getExtension()
si vous avez des infos par rapport à ca merci d'avance
Wind
17 août 2009 à 02:21
Désolé pour le temps de latence, mais j'étais pas vraiment dans les environs du net cet été...
Je ne sais pas comment tu essaies d'utiliser ma source, mais il suffit d'inclure le fichier init_xdir.php (il FAUT le faire) pour que le package soit utilisable.
8 juil. 2009 à 10:02
Fatal error: Class 'XDirFilter' not found in /var/phpcs_LISTING-REPERTOIRE-AVEC-FILTRES___Page/xdir-1.1.0/libs/filters/dir.filter.php on line 12
10 juin 2009 à 22:44
Vos m'faites marrer les gars, putain...
10 juin 2009 à 22:42
10 juin 2009 à 22:42
26 déc. 2007 à 22:50
Merci pour tes précisions.
Dans la mesure où j'ai besoin d'avoir toutes les extensions chargées et facilement accessibles, il me semble nécessaire de charger l'intégralité du contenu. Et à part en utilisant un objet SimpleXML, je ne vois pas comment faire... Un tableau PHP, avec la bonne clé, permettrait un accès rapide. Mais plus rapide que XPath ? Je ne sais pas. Et je ne me sens pas le courage de bencher chaque méthode.
Pour l'heure, j'ai apporté une correction (pas encore en ligne, et c'est pas pour tout de suite, n'étant pas chez moi pour une dizaine de jours) qui met en cache les informations des extensions (obtenues avec une requête XPath) dans un tableau (une variable statique de la classe FxpFileInfo). Ainsi, si on liste un répertoire ne contenant que des fichiers txt, la requête XPath n'est exécutée qu'une fois, les informations pour l'extension étant ensuite chargées depuis le tableau (ce qui devrait, quand même, être plus rapide avec un truc du genre $tableau['txt']['mime']). Si c'est pas plus rapide, je laisse comme c'était.
Concernant SimpleXMLIterator, j'y avais bien pensé (forcément, je cherche à utiliser la SPL au maximum). Seulement, ça ne me sert pas dans mon cas : je n'ai pas besoin de dresser une liste du contenu de mon fichier xml, mais d'accéder à n'importe quel élément à tout moment.
Bon. Voilà où j'en suis pour l'instant.
En tout cas, c'est le genre de débat dont je rafole... Donc n'hésitez pas à apporter des précisions de toute sorte quant à une optimisation possible. C'est intéressant pour le code, mais aussi et SURTOUT pour la culture geek (culture générale de développeur).
Encore merci pour les commentaires, et bonne fêtes de fin d'année.
26 déc. 2007 à 19:38
pour en remettre une couche sur le XML... :-) SimpleXML charge en effet tout le fichier ET le parse.
Mais le problème n'est pas vraiment de savoir si c'est très gourmand ou non. C'est surtout lié à l'utilisation que l'on en fait. XPath est extrèmement puissant, et poour une structure complexe, avec des recherches potentielles complexes, il est largement préférable d'implémenter du XML et XPath, qui feront ça en natif (LIBxml est écrit en C) plutôt que de créer un moteur de recherche dans un tableau multidimensionnel en PHP. Ce sera forcément bcp plus simple et bcp plus souple...et bcp plus rapide. Un tableau aussi est chargé en mémoire intégralement, selon comment on l'utilise.
Si on veut optimiser, il faut combiner XMLReader, qui fait du pull (c'est un itérateur, quoi). Mais il ne permettra pas de faire des requêtes XPath. Néanmoins, si on a des requêtes XPath à faire sur un noeud précis et connu du document xml, on peut très bien d'y déplaxer avec XMLReader, puis récupérer le noeud et le passer à SimpleXML, qui ne chargera donc que cette partie, et là, déclencher notre requête XPath.
Il y a aussi la possibilité de voir du côté de SimpleXMLIterator, dans la SPL.
24 déc. 2007 à 12:36
23 déc. 2007 à 17:03
J'ai développé ces classes dans le but de les intégrer à un explorateur. L'idée était de proposer un explorateur PHP5, orienté objet (alors que tout ce qu'on voit d'ordinaire n'est que du procédural PHP3).
J'ai voulu publier ces classes séparément pour deux raisons :
- le développement de l'explorateur est bien plus long que le développement de ces quelques classes : tout ce qui est interface graphique (IHM), Ajax, c'est pas mon fort. Je suis plus doué pour le traitement abstrait...
- j'en avais franchement ras le bol de voir des parcours de répertoires avec toujours la même boucle while (et encore, quand les gens font l'effort de l'écrire correctement, comme décrite dans la doc, ce qui est rarement le cas).
C'est donc aussi, pour beaucoup, un package à but didactique : oui, on peut parcourir un répertoire et afficher toutes les informations des fichiers, les filtrer, avec quelques lignes, faciles à lire.
Ces classes peuvent certainement être utilisées dans un autre but que d'être le coeur d'un explorateur. A ce moment là, la classe FxpFileInfo sert très peu. Ca me fait penser qu'il faut que je permette, lors de l'instanciation de FxpDirectoryIterator, de paramétrer ce qu'on souhaite obtenir avec la méthode getFileInfo(). En effet, la classe RecursiveDirectoryIterator prévoit que getFileInfo() peut retourner soit le résultat de getPathname(), soit un nouvel objet SplFileInfo... Pour un simple listing de répertoire, on peut se contenter de getPathname()...
Ca me fait donc deux choses à rajouter...
23 déc. 2007 à 16:55
Tu m'aurais dit "C'est pourri", je ne te cache pas que j'aurais été très désagréable. Simplement, mes réponses voulaient justifier certains choix faits dans mon développement.
Pour ce qui est de xpath, je pense que ce qui peut être mis en cache, ce sont les informations récupérées. Lors de la première requête xpath, on lit le xml. Si on doit à nouveau lister un fichier de la même extension, on va exécuter à nouveau la requête xpath, ce qui du coup, peut tout à fait être allégé : on stocke les informations de l'extension dans un tableau. Si l'extension a déjà été "lue", on va certes plus vite en récupérant la valeur dans le tableau qu'en réexécutant une requête xpath.
Ca allège d'autant plus que le fichier est volumineux, que le nombre de fichiers listés est important, et que certaines extensions sont récurrentes.
Donc je vais implémenter ça. Merci d'avoir attiré mon attention sur ce point.
Je reste persuadé (mais je ne sais pas comment le vérifier) que SimpleXML se contente de charger en mémoire un fichier XML, lors de son instanciation. Il ne le parse que lorsqu'il le lit. Mais en même temps que j'écris, je suis pris d'un doute... SimpleXML est quand même capable de vérifier que le fichier XML chargé est bien formé... Je suis pas assez calé en C pour aller fouiller dans les sources de l'extension... Mais je pense que l'information vaut la peine d'être connue.
Pour ce qui est des fichiers __init__, je me suis inspiré du chargement des classes en Python. En fait, je considère chaque répertoire comme un package indépendant. Tu noteras que si j'avais considéré chaque répertoire comme une classe, j'aurais fait un répertoire pour la classe filtre. Or je considère que les filtres font partie intégrante du package FxpDirectoryIterator.
L'idée, dans une vision globale de l'architecture d'un site web, est que dans le fichier classes.xml on ne déclare que les packages que l'on souhaite utiliser. Ce qui laisse libre le nom des fichiers de chaque classe, la gestion des déclarations au sein d'un package (nom de la classe pour le fichier, plusieurs classes par fichier, etc). Chaque package possède son propre fichier __init__, qui est appelé pour le charger (comme en python) : ce fichier peut ne faire qu'inclure d'autres fichiers, mais il peut aussi être utilisé pour faire des vérifications (par exemple, l'existance ou non d'une classe, comme pour DirectoryIterator).
Tu noteras que l'ordre de déclaration des classes est important : si tu déclares une interface après la classe qui l'implémente, lors de la définition de la classe, un message d'erreur survient pour signaler que l'interface n'existe pas. Cela permet de s'assurer, dans le __init__ que les classes sont déclarées dans le bon ordre.
23 déc. 2007 à 16:37
Pour ce qui est de la classe FxpFileInfo je parlais du fait qu'elle se base sur un XPath pour obtenir les données dont elle a besoin. L'idée est bonne dans le cas où SimpleXML fonctionne comme tu le penses. Le problème est qu'XPath va parcourir ton objet SXE et filtrer chacun des noeuds afin de trouver celui recherché. Or, une fois encore je me base sur mon propre avis et non des données techniques puisque je les ignore, je ne pense pas que le fichier XML soit indexé, mappé ou hashé, surtout si on part du principe qu'il est lu "au fut et à mesure que nécessaire". Auquel cas, les itérations de XPath se verront de plus en plus longues en fonction de la profondeur de ton arbre XML.
Je n'ai pas pris la peine de lire le README lors de mon premier commentaire, mais tu as raison. Si ce code sert seulement à un explorateur, il n'est pas utile de mettre en cache les données à la vue de la faible utilisation des pages. Toutefois, si ce code a été posté c'est pour être partagé voire réutilisé par d'autres développeurs qui eux, devront implémenter du cache et modifier tes classes peut être ! Voila pourquoi j'avais émis l'hypothèse du système de cache, permettre aux autres développeurs d'utiliser tes classes sans avoir à trop se soucier des performances associées.
Ta remarque sur le tableau en cache n'est pas juste. Le tableau n'a pas besoin d'être parsé au même titre qu'un fichier XML ! De plus, il est indexé ce qui accélère la recherche de données pour un offset donné, contrairement à XPath.
Pour en revenir aux fichiers __init__.php, puisque tu utilises des fichiers XML pour charger en quelques sortes les paquetages principaux puis les classes associées, pourquoi ne pas simplement combiner tes fichiers __init__ et XML pour charger toutes les classes en une seule fois, via un seul fichier XML ?
J'espère que tu ne vois pas mes commentaires comme des critiques négatives car ton code est très bon à mon sens.
23 déc. 2007 à 14:48
Merci pour tes remarques. Je vais répondre pour justifier quelques pratiques dans mon code.
Comme je le dis dans mon fichier README, ces classes font partie d'une application en cours de développement : un explorateur de fichiers. C'est pas le genre d'application multiutilisateurs avec 250 accès par seconde... Donc les performances, c'est pas la priorité (tant que la page ne met pas 3 h à s'afficher).
Pour la session, c'est un oubli : je vais l'enlever, elle ne sert à rien pour ces classes seules, elle fait partie du reste de l'application.
Le fichier de fonctions : oui, il ne sert pas à grand chose puisqu'il n'y a qu'une seule fonction. Mais encore dans le cadre de l'application complète, il a vocation à être étoffé. Pour sortir les classes du package, je ne me voyais pas tout réorganiser : juste supprimer ce qui n'est pas utile.
Les fichiers __init__ : tu trouves ça moche, moi je trouve ça très pratique. Parce que le fichier se charge (ahah) de charger les fichiers nécessaires au bon fonctionnement d'une classe. Dans ma méthode de développement, mon organisation, chaque classe se trouve dans un répertoire du même nom. Je n'utilise pas l'autoload pour ne pas forcer une application tierce (dans le cas d'une intégration de l'application, je veux dire l'explorateur ou autre chose) à utiliser les mêmes conventions d'autochargement. Ma fonction de chargement de classes fait ça très bien.
J'ai donc utilisé un fichier XML pour les classes à charger : parce que c'est plus pratique à modifier à la main.
Encore une fois, les performances que ça coûte là sont franchement insignifiantes pour l'utilisation de l'application.
Si on veut intégrer uniquement ces classes dans une application multi-utilisateur avec de plus nombreux accès, on peut changer ça. Mais je ne suis pas certain que les performances perdues soient si importantes que ça.
Quand au fichier XML des extensions, j'ai du mal à voir où est réellement le problème : le fichier XML n'est pas lu intégralement, il est juste chargé. Il ne me semble pas que SimpleXML parse le fichier dans son intégralité lors du chargement. Il me semble que, justement, il le parcours quand on itère dessus.
La requête xPath est peut-être lourde (d'autant qu'elle cherche un élément d'après la valeur d'un attribut), mais j'ai du mal à voir comment on peut l'alléger. Mettre en cache : je ne vois pas l'utilité, si le fichier n'est pas parsé lorsqu'il est chargé. Donc que le fichier fasse 20 ou 1000 lignes, la principale différence réside dans l'espace mémoire alloué.
Mais je me trompe peut-être sur le chargement d'un objet SimpleXML (vais creuser de ce côté là).
Autrement, mettre en cache dans un tableau PHP, ça implique que, pour le coup, l'intégralité du fichier est parcouru lors du chargement. Je ne vois pas ce qu'on y gagne.
Mais je le concède : certains ici sont bien plus aptes que moi à évaluer les différences de performances dans un cas ou un autre.
Si tu as quelque chose à me proposer pour améliorer ça, je suis preneur.
En quoi FxpFileInfo.class.php est une monstruosité ? Tu dis ça à cause de l'utilisation du fichier xml ? Ou bien... ? Si tu peux développer...
23 déc. 2007 à 14:18
Dans le fichier fxp/fxp.inc.php tu ouvres une session (session_start). Tu devrais tester si la session est déjà ouverte afin de ne pas provoquer d'erreurs si quelqu'un décide d'utiliser ton code. Je te conseille d'utiliser des espaces de nommage pour tes sessions afin de ne pas écraser d'éventuelles autres sessions existantes.
Ton fichier fxp/core/functions.inc.php ne sert pas vraiment. Je te conseillerais d'inclure ce code dans fxp/fxp.inc.php. Pour ce qui est de la fonction fxp_import_classes(), je te conseillerais de ... ne pas utiliser un fichier XML mais de charger tes classes en dur. Si tu veux tout de même utiliser du XML, mets en place un système de cache afin de ne pas charger et parser le fichier XML à chaque appel ! Les fichiers __init__.php c'est moche. Tu inclus un fichier qui fait des inclusions, autant inclure directement les fichiers cibles. Tu y gagneras en performances.
Là, ça va saigner ... fxp/core/classes/FxpFileInfo/FxpFileInfo.class.php et fxp/core/classes/FxpFileInfo/extensions.xml sont deux monstruosités ! Certes le code n'est pas trop mal mais c'est un gouffre à performance ! Le fichier XML ne fait pas moins de 1100 lignes et tu ne mets même rien en cache. De plus, XPath c'est fantastique, mais ça consomme aussi énormément de ressources. Je ne serais que trop te conseiller de revoir cette partie du traitement.
Sinon pas grand chose à dire sur le reste, que du bon.
Joyeux Noël :)
22 déc. 2007 à 22:01
Je mets à jour l'archive.
22 déc. 2007 à 20:21
Warning: require_once(/usr/local/www/html/www/clients/fxp/core/config.inc.php) [function.require-once]: failed to open stream: No such file or directory in /usr/local/www/html/www/clients/fxp/fxp.inc.php on line 5
Fatal error: require_once() [function.require]: Failed opening required '/usr/local/www/html/www/clients/fxp/core/config.inc.php' (include_path='.:/usr/local/lib/php:/usr/local/share/pear:/usr/local/www/html/pastebin/lib') in /usr/local/www/html/www/clients/fxp/fxp.inc.php on line 5
le fichier config.inc.php ne se trouve pas dans l'archive!!!