Discussions sur Talus' TPL

Bonjour,

Je suis jordan du site du zéro et elementaire de Assembla. J'ai forké ton projet sur mon espace personnel Assembla.

Je suis en train de parcourir ton code, tu recevras certainement plusieurs mails de ma part.

J'ai deux objectifs :
- améliorer l'existant en abordant des bugs et en détaillant des aspects étranges ;
- proposer une réflexion sur la version 2.

Je débute ce premier mail par ma vision de la prochaine version majeure.

Commençons par l'organisation de l'arborescence. Je pense qu'il est usage (à l'utilisation) de récupérer un dossier contenant toute la librairie et de le caler dans lib. Le dossier lib provient de l'utilisateur qui ajoute simplement ta librairie à son projet. Du coup l'arborescence de ton projet est étrange et inadaptée.

Concrètement, je verrai plutôt quelque chose comme :

/lib/Talus_TPL/CHANGELOG
/lib/Talus_TPL/LICENSE
/lib/Talus_TPL/Talus_TPL.php
/lib/Talus_TPL/Caches/
/lib/Talus_TPL/Compilers/
/lib/Talus_TPL/Exceptions/
/lib/Talus_TPL/Filters/
/lib/Talus_TPL/Interfaces/

Tu remarqueras que dans ce modèle trunk est remplacé par Talus_TPL ; je pense que ça devrait être comme ça dans les archives que tu fais télécharger. Je sais qu'il est d'usage de nommer le dossier de développement courant trunk. Sa présence sur Assembla ne me choque donc absolument pas.

Ce qui est plus fâcheux pour un projet libre, c'est de ne pas avoir les fichiers sources des anciennes versions dans d'autres dossiers comportant la version dans leur nom :/ Certes, tu ne les maintiens plus, mais ça pourrait intéresser d'autres développeurs.

Le fichier Talus_TPL.php permet l'utilisation du moteur de Template complet comme c'est le cas actuellement, il suffit de l'inclure.

Les fichiers CHANGELOG et le LICENCE ne varient pas.

J'ai créé directement une série de dossiers. Caches, Compilers et Filters permettraient de stocker les dépendances du moteur : la tienne utilisée par défaut et celles des autres développeurs. L'intérêt est qu'à partir de ton moteur de Template, un développeur peut forker n'importe quelle type de dépendances puis effectuer des modifications pour tester une nouvelle approche (algorithmique) ou adapter à un nouveau contexte (cache dans une base de données). Suivant le contexte, il peut utiliser telle ou telle dépendance.

Je n'ai pas défini si une dépendance de filtre correspond à un unique filtre ou à un ensemble. A voir. L'idée est toujours de charger que l'utile suivant le contexte.

Les exceptions d'exécutions, de parses, de dossier, etc propre à Talus TPL resteraient dans un dossier dédié et son contenu serait étoffé.

Les interfaces qui valident les dépendances ou celles propre à Talus_TPL seraient également dans un dossier à part.

Dans ton modèle actuel, une instance de Talus_TPL correspond à génération au maximum de combien de ressources différentes (image, page web, fichier css/js etc) ?

Je sais qu'en 10 minutes, je viens de bouleverser de manière importante ton projet, j'espère que tu n'es pas fermé et prêt à en débattre.

Cordialement,
Jordane VASPARD

Hello,

Merci de ton intérêt pour Talus TPL (le fait que tu le fork ne me pose aucun problème, du moment qu'il y a respect de la license (citation de l'auteur d'origine), et non, je suis très ouvert à la discussion. :)

Tout d'abord, pour la gestion des dossiers. Avant la prochaine version (donc jusqu'a la version actuelle -- que dis-je, dans la dernière version, où j'ai implémenté l'autoload), il y avait juste les fichier CHANGELOG & LICENSE qui était en dehors du dossier Talus_TPL. La classe Talus_TPL.php, en elle-même, était toujorus dans le dossier. Mais finalement, ce que je pensais, c'est que si quelqu'un télécharge la lib (ce n'est pas un développeur qui souhaite bidouiller la lib si il se contente du .zip / .tgz ; si c'est du svn, c'est une autre histoire...), il aura juste besoin du fichier Talus_TPL.php et du répertoire correspondant.

Ainsi, les dépendances de la classe Talus_TPL sont dans le dossier du même nom ; on sait ainsi que la classe aura besoin de tel ou tel objet. Le coup de nommer le répertoire trunk, en général, comme tu l'as dit, c'est une convention pour dire "c'est la branche de travail actuelle". Donc normalement, en faisant un update dessus, on veut juste le contenu du répertoire. Pas le répertoire trunk en lui-même.

Ensuite, pour les dossiers que tu proposes, Filters n'en a pas vraiment besoin d'un dossier, vu que c'est une simple classe.. Qui est finale. Je ne penses pas que, à l'avenir, qu'il y ait quoique ce soit à forker dessus, si ce n'est ajouter des filtres... Ce qui demande donc un bidouillage de la classe elle-même. Pour le Cache & le Compiler, C'est à peu près pareil (ptet le compiler) ; Le cache il y a UNE classe pour le gérer. Si le développeur veut faire son propre cache (eaccelerator, bdd, apc, ...), il aura juste à implémenter l'interface, et les dites méthodes... Et écraser l'existant cache.php, vu qu'il ne sert plus à rien. Donc ca ne limite le cache qu'a un seul et même fichier / package, rendant inutile le dossier.

Pour le Compiler, par contre, à la rigueur, je peux envisager de le mettre dans un dossier, puisque pour l'étendre à sa propre sauce, il faut étendre la classe Compiler. Donc oui, pourquoi pas...

Concernant l'emploi des ressources, ça dépend vraiment du développeur... Vu qu'a la base, il génère vraiment *que* le contenu choisi (soit un fichier css / js par exemple, ou bien une page web -- une image, à moins de parler le base64 couramment en 2ème langue, j'en doute), mais au maximum, je ne saurais dire. Vu qu'une fois que c'est parsé, c'est juste du php exécuté comme un script normal... Donc il n'y a pas vraiment de maximum, du moins c'est ce que je pense.

Encore une fois, je vais revenir sur l'organisation des dossiers. Le problème, c'est qu'a force de faire trop de dossiers, ben... On s'y retrouve plus. Et spécialement pour l'autoload. Je sais pas si tu as regardé ce morceau, mais pour charger les exceptions / interfaces, il le traite au cas par cas ; alors traiter 2 cas de plus (Cache & Compiler), ou même un cas de plus (Compiler), c'est que ca revient à faire un gros if / else bien chimique et pas vraiment adapté... J'admet que cette méthode est à améliorer, mais comment, là est la question.

J'en profite pour répondre à ton deuxième mail ;

Pour le bug, merci de me l'avoir signalé, je pense voir à présent pourquoi. En effet, c'est l'exception Talus_TPL_Exception, mère de toutes les exceptions, qui foire avec le système dit d'autoload. Merci pour le retour, j'en prends note... Il faut, en effet, dégager le "Exception" du nom de la classe que si ce n'est pas la classe mère (donc qu'il n'y ait plus qu'un seul élément une fois le nom de la classe splité).

Implémenter un mode VERBOSE en développement... Là je ne suis pas vraiment très convaincu de l'utilité. Développant seul, quand j'ai besoin de tester, c'est donc à la va vite (oui je sais c'est pas bien). Mais j'y réfléchirai, car bien que n'étant pas vraiment convaincu, je compte quand même me faire un avis définitif. Ca pourrait aider ceux qui veulent étendre les classes Talus_TPL.

Et pour les deux Bugs de TWK : OK c'est pris en note. Ca fait assez longtemps que j'ai pas trop touché au code de TWK (ayant forké le TPL en dehors, laissant celui sur TWK sans maj)... Car je compte aussi faire une V2 dessus éventuellement, qui changerait un peu la structure du site (d'où la flemme de continuer à coder sur la v1)... Mais j'y jetterai un oeil ou deux. :)

Si tu as d'autres questions / remarques / suggestions, n'hésites pas.

Cordialement

Re,

Oui j'aime bien répondre au dessus du mail et non pas en dessous. Comprendra qui pourra.

Dommage que tu n'es pas de micro. Parler me permet de communiquer beaucoup plus rapidement mes idées que par mail. Je me console en me disant qu'il y aura une trace écrite. Je t'ai ajouté à mes contacts msn (non retranscrit ici. :-°).

Je ne suis pas sûr d'avoir bien été compris, donc je reformule. Le dossier Talus_TPL est en trop je trouve. A partir du moment où l'utilisateur se sert de ta librairie, il sait qu'il a besoin de tout le reste. Ca constitue un niveau hiérarchique (de dossier) en trop.

Logiquement, il ne mélange pas ta librairie directement avec les autres mais la place dans un dossier dédié. Bref, Talus_TPL.php n'est pas directement dans ./lib/Talus_TPL.php mais dans ./lib/Talus_TPL/Talus_TPL.php Je m'en rends compte que c'est surtout une question de point de vue selon dans quel dossier est placé le point d'entré d'utilisation de chaque librairie.

Je suis partagé sur ton avis sur le dossier Filters. Pour le moment, tu as créé une bibliothèque de méthodes encapsulés dans une classe. D'un point de vue orienté objet, c'est douteux. Si ça s'expliquait par la pauvreté de l'OO Php, je pense que depuis la création des espaces de noms, ce n'est plus le cas.

Pour le moment, tes filtres sont très basiques voire gadgets et n'agissent que sur la couche de présentation (on joue avec les majuscules et les minuscules). Je caricature un peu. C'est une vision très limité de l'utilisation du web.

Moi, j'envisage sans rigoler très bien un ensemble de filtres dédiés à l'affichage des dates (Aujourd'hui, hier, il y a, age)... Ca pourrait par exemple faire un package dédié. On peut en envisager un autre pour la gestion de l'affichage des nombres (utilisation des , ou . ajout des espaces nécessaires pour les grands nombres, conversion en texte, chiffre romain ou
autre). Je pense même à un troisième package qui gèreraient les valeurs monétaires (conversion à la volée etc).

En très peu de mots, j'ai enrichi tes filtres de nombreuses fonctionnalités.

J'espère que tu comprends alors mon point de vue, ces modules ne sont pas nécessaires à chaque fichier Template. Ils pourraient être chargés à la volée et sont maintenant assez nombreux pour nécessiter un dossier. En effet, je pense qu'il est exagéré de regrouper toutes ces fonctions dans une seule classe / fichier.

En réfléchissant comme ça, tu associes facilement les développeurs libres à ta démarche : ils pourront fournir de nouveau package et les intégrer sans peine puisque que ça a été pensé pour.

Comment peut-on traduire cette idée dans un tpl ? Je te propose ça par exemple : "J'ai {CapitalEuros} euros ce qui fait {CapitalEuros|monnaie.euros2francs} francs". Ce n'est pas une version définitive, ça doit être débattu mais ça exprime bien ce que je veux dire.

Tu dis qu'il existe une classe cache et qu'il suffit de la remplacer pour profiter d'autres fonctionnalités perso. Imaginons que j'ai plusieurs traitements différents selon le type de la ressource : je mets mes css et js dans memory, mes images dans le système de gestion de fichier et mes fichiers php en bdd. Plutôt que d'avoir simplement défini quel dépendance de cache j'utilise, je me retrouve avec un seul choix dont le code est bourré de test suivant le contexte. Pas sûr que ce soit plus simple et plus productif à maintenir.

C'est un peu la même chose pour le compiler. Ca apparait d'ailleurs dans ton code. Il existe plusieurs niveaux d'éléments à parser qui ont un sens selon le contexte. J'ai envie de dire, faisons varier le compiler plutôt que de faire des tests inutiles dans l'unique compiler. J'ai besoin que d'afficher des variables. Parfait, j'utilise le compilateur de base qui fait que ces remplacements. J'ai besoin de faire des choses complexes, d'ajouter des comportements, j'écris mon propre compiler qui dérivera probablement d'un autre. Mutualisation du code tout en conservant l'indépendance des transformations..

Ma question sur le nombre maximum de ressources générées par le template n'était pas une question piège. En fait, je me demandais si on pouvait réinitialiser l'objet afin de travailler à la création d'une autre ressource dans le même script php. Peu à peu, découlera la question d'utiliser un pattern singleton sur le template sauf si on souhaite générer des ressources en parallèle dans le code.

Le nombre de dossier est un faux problème puisqu'il est fixe. Ce que je veux dire, c'est qu'avant même l'exécution tu les connais. Au final, tes classes seront dans : racine ou exception ou ... ou filters.

Je caricature le code, et je propose une solution par forcément optimisée :

Code PHP <?php
__autoload() {
  if(is_readable('./exception/'.$className.'.php')) {
    include './exception/'.className.'.php';
  }
  else if(is_readable('./.../'.$className.'.php')) {
    include './.../'.className.'.php';
  }
  else {
    throw new Talus_TPL_Exception_Class_Not_Found;
  }
}

Rien de sorcier.

Les VERBOSE, c'est bien pratique pour suivre ce que le script fait. Alors oui c'est destiné aux développeurs principalement (pendant le développement lors de l'ajout de fonctionnalité, mais aussi pendant l'étude du code et lors des débug). Faut voir après si tu comptes continuer à développer seul
dans ton coin, ou comme le suggère ta licence, en faire un vrai produit libre avec des contributeurs extérieurs (comme moi par exemple).

Pour information, je ne m'intéresse pas à la branche TWK mais seulement à Talus TPL. J'ai signalé quelques bugs à l'occasion de mon mail précédent.

++