Personellement sous Mac, je n'ai absolument jamais eu aucun de pb pour installer un serveur MySQL... Jamais eu cette histoire de conflit :-/
Sinon, si tu te sens frileux, tu peux toujours installer XAMPP ( http://www.apachefriends.org/en/xampp-macosx.html )

Sinon pour le code, le coup d'ouvrir les fichiers (avec fopen) pour tester s'ils sont présents sur le disque, ça me semble un peu lourd. Même très lourd. Regarde du côté de la fonction file_exists ( http://fr2.php.net/file_exists ).

Aussi, prends l'habitude de coder en anglais. Des fonctions et noms de variable en français avec une syntaxe en anglais, c'est pas très beau. Et surtout, pas portable du tout.

Malalam > $session = new Session; $session->bla = array(1, 2); ? Non ?
Ou alors j'ai mal compris ta question...

Et pourtant il y a en a !
onCreate, c'est quand la requête vient d'être lancée avec succès (pas forcément effectuée), ça permet donc de faire quelque chose juste après.
onInteractive, ce sont les résultat partiels renvoyés, et pour l'avoir utilisé, je peux t'assurer que c'est assez utile.
De toute façon, si javascript et Prototype avec Ajax.Request fournissent ces possibilités, c'est justement parcequ'il peut y avoir une utilité :)

Personellement, je ne fais plus jamais d'ajax sans prototype :p

Je n'ai pas testé la source en elle même, mais je trouve très peu pratique et encore moins efficace la façon dont tu passes les paramètres à ta méthode.

Je veux dire, il aurait été beaucoup plus intéressant de faire :

# ObjAJAX.setParam ({
# url: "http://yoururl/index.html",
# returnFormat: "txt",
# method: "POST",
# data: [{valeur1: "1", valeur2: "2"}],
# asynchronus: "true",
# callback: function (response) {document.body.innerHTML = response}
# });

C'aurait été tellement plus simple...

Et puis, Ajax.Request de prototype est plutôt assez complète, d'autant plus qu'elle permet de faire des callbacks intéressants : onComplete, onFailure (très intéressant ça), onInteractive, onCreate, etc.
Je t'invite à visiter : http://www.prototypejs.org/api/ajax/options :)

Et comme le dit coucou747, cette source n'apprends rien à personne. A part un location.href ou un document.getElementById, ta source ne fait strictement rien :-/

Et même pour simplifier le code, plutôt que de faire :

# if (is_executable ($this->sRoot.$this->sCurrentFile) === true)
#   return true;
# else return false;

Tu peux faire :

# return (is_executable ($this->sRoot.$this->sCurrentFile));

Vu que ces appels renvoient déjà TRUE ou FALSE, ça fait redondant de dire "Si c'est TRUE, on renvoie TRUE, et sinon (si c'est FALSE donc), on renvoie FALSE.

Par habitude, je précederais toutes les variables censées être private/protected par des underscore :
# var $_sRoot;
Même si je sais que le concept de private protected n'était pas encore vraiment là dans PHP4, c'est toujours une bonne habitude :p.

A part ça très bien ! Propre, etc. Même la vérification de l'existence de la classe "DirectoryIterator". Tout le monde n'y pense pas, mais c'est pourtant tellement essentiel :p

Bravo en tout cas :)

http://www.php.net/~derick/meeting-notes.html#move-ereg-to-pecl
> Les expressiosn régulières POSIX (eregi, etc.) seront "deprecated" dans PHP6. De toute façon, rien d'étonnant, c'est moins perfomant et moins puissant que PCRE =) (les fonctions preg_*)

Juste pour info aussi :
Bien loin de moi l'idée de vous contredire sur le principe, mais PDO ne fonctionne pas par itérateurs, et renvoi bel et bien un tableau de données.

Je ne dis pas que c'est bien, mais PDO n'est pas non plus à cracher dessus, même s'il est loin d'être une référence.

De toute façon le mieux à faire, ça serait de coder tout ça en extension C :p
(A condition de bien coder en C bien évidemment...)

C'est peut-etre tout con, mais pourquoi faire un try catch sur une fonction (getimagesize) qui ne lance aucune exception ? :p
D'autant plus que tu inhibes l'erreur avec le @ devant, donc bon... =)

Bon c'est sur, mieux vaut être parano que laxiste, mais bon :p

Après le code en lui même, je dois t'avouer que face à un si gros paté, j'ai un peu du mal. C'est pas très aéré.

Mais il y a l'air d'avoir du boulot. Tu aurais une URL d'exemple ?

Je vois qu'on est tous d'accord.
Faire une méthode pour un return d'appel d'une fonction, c'est idiot... :)

"Mais je comprend ton point de vue, il est vrai que quelques fois, ca rend le code plus lisible. (je le sais, je le fais moi même :p )"
>> C'est pour ça que je disais qu'ici, ça n'était pas vraiment nécessaire, mais quand j'ai vu la taille du construct, même si raisonnable, ça m'est venu à l'idée, donc bon, j'ai dis. XD

Raaaa tu me prends au mot XD
Nan bon, je vais essayer d'être clair.

La classe présentée ici n'a rien d'idéale. La méthode _calculteMyOwnSHA1 déjà montre bien que pour une raison X ou Y, j'avais envie de refaire sha1. J'aurais pu mettre : _calculateMyOwnFileHash()... C'eût été plus clair.

Pour les commentaires, je suis d'accord que j'ai oublié de les mettres, mais j'en ai pas mis parceque voilà ! (non mais ho).

Pour la BDD c'était pareil, c'est un exemple qui m'est venu en tête... Genre une méthode qui appele PDO, qui faire des requêtes au préalable (genre stockage de l'IP ou je ne sais quoi), qui récupère par exemple la date de dernière connexion, et puis hop on continue.
Ce n'était pas une méthode de gestion de BDD hein. Suis pas fou non plus ;)
Mais la faute me reviens : je n'ai pas été assez clair du tout. Désolé.

En fait, la raison pour laquelle je code comme ça, c'est que j'aime bien avoir une méthode pour une action. Donc même si le rôle du constructeur est de construire, et il a donc un rôle multiple, je préfère sous-diviser les tâches pour appeler des méthodes qui ont un rôle unique.
C'est tout :)