C'est du joli travail, j'adhère vraiment de plus en plus à ton mini-framework !

Quelques petites choses supplémentaires histoire de l'améliorer :

Dans la classe TestUnitaire, il te manque une fonction fail($message) qui permet de forcer le log à afficher un statut de fail sur le test en cours. C'est utilisé si on sort d'un simple assert :

if ($cond1 != $val && ($cond2 > $max || $cond2 < $min) fail("valeur aux limites);

D'ailleurs tu peux aussi lors de la génération des classes la rajouter (dans TestManager --> write_method : dans le corp de la méthode rajoutes :
$this->fail('Not implemented yet');

Dans le TestManager toujours, dans la méthode launch, fais un try catch sur l'exécution du test car les erreurs peuvent faire arrêter le test sinon, à logguer aussi dans le statut d'exécution.

Il ne manque plus grand chose à ta librairie, juste le packaging : un nom de projet, de la phpdoc sur les classes, un repository SVN et un site web (sourceforge est pas mal pour ce genre de choses). Si tu le mets sous GIT (https://github.com/) je vais peut-être en faire un fork :)

En tout cas merci de partager ton source, je vais surement l'utiliser :)

Bonne prog et tiens-nous au courant,
akh

C'est très bien, pour les setup et teardown - ça permet de se créer un contexte de tests ISO et mieux cloisonnés - important pour éviter les effets de bords de certains tests - petit bémol quand tu sort du scope du $this le cloisonnement n'est plus géré ($_REQUEST, $_SESSION, $GLOBALS ... appels vers des variables statiques) - mais ce type d'effet de bord est très minime.

Parcontre je ne mettrait pas les appels (setUp, test_..., tearDown) dans l'instanciation de la classe de test mais je ferais une classe TestManager à part, qui elle lencerait par exemple les tests sur une classe, ou sur un ensemble de classes. L'objet devrait à mon sens être reconstruit à chaque execution de test.

La classe de log c'est bien la class Débug que tu as actuellement, elle devrait effectivement être en mode singleton et juste stocker les infos.

La classe TestManager s'occuperait de dumper les résultats en fin de test par exemple. Pour la structure de débug, faudrait rajouter un niveau de log sur la classe en cours d'execution vu que c'est multi-classes.

J'utiliserais les classes de Reflection dans le TestManager pour gérer les annotations de documentation, histoire d'associer des commentaires aux fonctions testées et de les affichers dans les résultats.

NB : Un truc utile dans le TestManager est de pouvoir générer un fichier de test unitaire en lui passant en argument un nom de classe.

Si tu peux faire le tout en moins de 1000 lignes de codes, tu tiens un framework de tests unitaires complet et surtout facile d'utilisation.

:) bon courrage

Bonjour Pierre,

Un source très intéressant, les asserts en PHP sont assez peu utilisés donc c'est très instructif d'en voire un exemple.

Le code est très simple et j'aime ton approche KISS et justifiant le fait de ne pas passer par un framework de type PHPUnit.

Je commence par un point "obscur" sur le :

$this->_return[$this->iNbError][$config] = $$config; la liste des clés étant limitée par la signature de la fonction je ne vois pas trop l'intérêt de cette boucle.

Un simple code aurait pû suffire :

$this->_return[] = array(
  'line' => $line,
  'code' => $code
);

--> Pour faire un peu d'optimisations :) <--

Dans la classe Debug :

- Les variables iNbError, et _config n'ont pas besoin d'exister
A la place de iNbError, tu peux utiliser : sizeof($this->_return)

- De la manière dont tu as écrit ta classe Debug n'est pas un singleton, donc soit supprimer oInstance soit en faire un vrai : cf partie PHP 5 : http://fr.wikipedia.org/wiki/Singleton_%28patron_de_conception%29

Dans la classe TestUnitaire :

- J'aurais plutôt mis l'instanciation des asserts dans les DEBUG

- Pour permettre d'instancier les asserts à partir des DEBUG j'aurais éventuellement loggué dans Debug toutes les assertions, ainsi j'aurais également eu le log de tout ce qui est OK.

Sur le principe, il me manque un élément, c'est le contexte d'implémentation des tests unitaires : je présume qu'actuellement on doit le fait en bloc dans le construct. Au passage dans la classe TestUnitaire ton __construct devrait être final public pour éviter les effets de bords de l'héritage.

* Y'à t'il moyen d'avoir un cloisonnement des contextes avec plusieurs fonctions ...
* Si dans une exécution on veut exécuter plusieurs classes de tests à la fois ...

Si tu règle ces petits points je pense que ta classe à vraiment un bon potentiel car c'est pas vraiment intéressant de déployer, configurer et customiser PHPUnit, alors que ton code serait beaucoup plus facilement adaptable.

Bonne continuation,
akh

J'ai hâte de lire ton tuto car je suis un peu imperméable aux formules mathématiques et théoriques et le site de Levee ne m'a pas plus aidé. Je trouve que la théorie des ensembles embrouille plus que n'explique, un bon tuto et une bonne dose de vulgarisation ne ferais pas de mal :))) surtout qu'après quelques recherches acharnées sur google j'ai rien trouvé de convaincant.

Bon courage pour ton tuto et merci pour cette source :)

Petite correction à la fin de ton code, faut utiliser NodeParser au lieu de XMLParser.

En lisant le code je me rends compte que le buffer initialement utilisé est tronqué par son début à chaque itération (unbufferize), cela ne risque pas sur des gros buffers de ralentir le parsing ? Y'à t'il une raison pour laquelle on ne pourrait pas tout simplement utiliser une boucle et itérer sur un curseur qui avance sur le texte ?

Autre point, c'est que l'accès au buffer se fait de manière statique ce qui ne devrait pas trop être dérangeant, mais je me demandais pourquoi ne pas avoir utilisé des instances d'objets, ce serait la même conso mémoire, avec la possibilité de créer plusieurs instances chacune ayant son contexte ...

Sinon j'adore le côté simple ... mais j'aurais fait une classe reader à part de la classe qui parse (cela permettrait de lire un buffer ou un fichier selon le reader utilisé).

Je viens de lire un article wiki sur le sujet, je ne suis pas pour autant plus avancé ... pourrais-tu revenir un peu sur le principe de fonctionnement des parseurs LL car à priori ils ont l'air assez puissants ...

RIEN QU'UN MOT : J'ADORE !!!

J'ai bossé sur un parseur mais j'ai fait l'implémentation de manière intuitive, et après quelques refactoring je suis tombé sur quelque chose d'assez similaire, mais un peu trop lourd à mon sens.

Je l'essaye et je reviens pour te faire un retour, en tout cas merci pour ce code.

Manu je ne pense pas que tu vois vraiment où je veux en venir... tu cherches à écrire du SQL dans ton flash et c'est là tout le problème, et cela ne se limite pas à la sécurité.

* Flash = exécution côté client = présentation (principe MVC)
* PHP = exécution côté serveur = modèle / contrôleur

Pour faire simple, t'as pas trop le choix ... aucun framework ne permettrait d'embarquer la logique métier et le mapping côté client.

De plus, tu fais aujourd'hui du flash ... OK
Demain tu veux faire un petit soft en .NET en client lourd ... tu refais toutes les requêtes ?

La partie IHM (=côte client) est la partie la plus évolutive et la plus sujette aux évolutions techniques ... embarquer la logique métier ne servirais qu'à l'alourdir voire même t'obliger à la faire évoluer ou la ré-écrire en changeant de techno.

Maintenant côté code, rien ne t'empêche de faire la même chose que t'as fait style mysql.remplir(...); en version plus propre :

Ton service PHP retourne un array de valeurs, il est exposé style : http://domaine/services/MyService/GetItems.xml
(par exemple : le .xml indique qu'on attend du XML)

Ton SDK côté flash aurait un truc du style :
conn = SDK.Connect("http://domaine/");

Coté classes AS tu aurait une class de mapping :

class MyService {
  ... conn;
  public MyService(conn) ...    
  ArrayList GetItems() {
    return conn.Request("MyService", "GetItems");
  }
}

Tu peux faire :
service = new MyService(conn);
ArrayList items = service.GetItems();

Ou bien tu te fais un helper pour reproduire ta fonction :
Helper.Assign(service.GetItems(), this);

C'est très schématique, mais cela te montre que plus tu as de niveaux d'abstractions et plus tu as moins à travailler.

Concernant l'attaque sur ton domaine : www.as-ql.org, tu dois t'assurer que l'attaque ne vient pas de l'intérieur.

Je te donne quelques exemples : tu fais un logiciel de facturation en flash, tu ne peux pas le proposer en SaaS (ou imagines sinon que les concurrents vont aller s'espionner entre eux).

Tu fais un logiciel collaboratif là encore tu peux pas, du moment où les utilisateurs n'ont pas tous les mêmes droits ou des droits restreints ta librairie n'est pas utilisable ...

Tu fais un jeu dans lequel les gens peuvent y inscrire leur score, tu fais un formulaire de d'inscription à une newsletter, un formulaire de vote ...etc...

Tu peux faire un très joli truc, fais les couches que j'ai décrit dans mon précédent message et puis rajoutes unes couche RAD comme tu l'as déjà fait pour ton framework ...

Bon courage pour la suite de tes dévs :)

:)) c'est une version 0.0.0.0.1 ! je suis d'accord avec l'indulgence mais bon c'est vrai que cette source n'a pas vraiment d'utilité, faire un scrolling horizontal y'à aucun intérêt à le partager ...

sois un peu plus perfectionniste, bosses 1 mois s'il le faut mais abouttit à un résultat que tu seras fier de présenter, à une époque sur CS dès que tu publiais un code de calculette (avec un algo pourtant) il se fesait directement éjecter ...

Hello Manu,

J'ai bossé sur quelque chose de très similaire (publié sur flashkod : http://www.flashkod.com/codes/CLASSE-LIAISON-REQUETTAGE-AVEC-SERVEUR-MYSQL-DISTANT-XSQL_38305.aspx) mais avec la notion de sécurité en moins compliqué, mais avec les mêmes failles qu'a relevé Peg.

Je pense comprendre un peu vos deux problématiques, et peut-être qu'un peu de retour sur mon expérience va t'éclairer.

A première vue Peg à l'air de chercher la petite bête mais en réalité il a tout à fait raison, c'est juste qu'il ne l'exprime pas assez clairement :

Je voulais faire du SQL dans du flash, comme j'aurais très bien pu le faire en ajax / javascript. Le problème peut ne pas se poser à première vue car l'utilisateur exécutant le code est identifié, donc un guest ne peut pas nuire.

Le problème se pose à deux niveaux :

- l'utilisateur connecté peut lui avoir plus de droits qu'il ne devrait ... mais étant faignant de ce côté je m'en fout du moment où ça m'aide (j'estime qu'être faignant en informatique est une qualité au passage :)

- autre problème c'est la logique métier et la ré-utilisabilité et c'est là que le bat blesse :)

Etant faignant je ne voulais pas avoir à écrire le SQL à chaque fois, répéter des règles métier complexes, ou bien en changeant la structure repasser par des kilomètres de code.

Du coup quand tu deal avec des bases de données, la bonne pratique veut que tu en fasses des objets. Le choix de l'environnement où tu fais ton objet est important, on pourrait être tenté de le faire en flash (avec tous les problèmes que ça pose au niveau sécurité) ou bien le faire côté PHP, permettant ainsi de partager les ressources côté ajax, flash, ou bien un MVC classique avec des vues en HTML.

Donc pour répondre à ta source, tu as raison sur le fond, mais tu t'y prends de la mauvaise manière.

Ce que t'aurais dû chercher à faire :

Une partie API :
- c'est d'intégrer un ORM, avec un DBAL
- faire des helpers pour la sérialisation : XML, JSON, CSV ...
- un équivalent de ton data.php pour le routage des appels en mode REST, et utilisant les helpers pour exprimer les retours
- un mode session ou quelquechose d'équivalent permettant de sécuriser l'appel de certains services

Une partie SDK :

- des classes de base pour les autres languages
* Flash
* Javascript
- éventuellement si tu est motivé, à partir d'une classe PHP tu peux générer l'enveloppe AS ou JS te permettant de ne pas perdre du temps sur une seconde re-définition (cf PHP+Reflection).

Dans le principe ça serait un peu similaire à ça : http://www.phpcs.com/codes/AJAX-TOOLKIT-PARTAGE-CLASSES-ENTRE-PHP-JS_47075.aspx

------

Lorque t'enchaines sur la création d'un nouveau projet avec ton framework, tu fais côté PHP tes classes qui gèrent la base de données, et puis tu inclues dans ton flash les enablers AS qui leur correspondent.

Le tout sera : optimisé, sécurisé, simple, ré-utilisable, évolutif

Bon courage, si tu ponds un projet comme ça n'hésites pas à me prévenir :))
akh

Le REST (Api AJAX) est à la mode ces derniers temps et c'est très simple de comprendre le pk, c'est tout simplement plus compatible contrairement à SOAP...(je suis pas trop d'accord avec lefauve sur le manque d'utilité d'une classe exploitant REST plutôt que du SOAP)

Pour le côté PHP (alors que REST semble que pour JavaScript) ça se justifier, car même si une alternative SOAP existe, c'est plus sympa de faire un file_get_contents sur une URL avec des paramètres en GET plutôt que d'utiliser des librairies SOAP qui ne sont pas distribuées par défaut sur toutes les versions...

J'insiste un peu sur cURL mais dommage de l'avoir utilisé forçant à avoir cette librairie, et le côté obscur de REST étant, vu que c'est moins formalisé je spaghéttise mon code ... les retours JSON devraient être toujours encapsulés dans des classes spécifiques ...