1 réponse par metagoto

(20 réponses, posts Actualités)

Hywan a écrit:

Un jour je serai qui tu es

lolol mdr. mo joré mi "Je saurai" XD
big_smile

Voir le forum: Actualités

2 réponse par metagoto

(20 réponses, posts Actualités)

Hywan a écrit:

on a parlé de toi plusieurs fois au PHPTour, hehe.

Hé ben, vous ne deviez pas avoir grand chose à dire lol

Voir le forum: Actualités

3 réponse par metagoto

(20 réponses, posts Actualités)

Salut.

Je n'ai pas trop suivi l'affaire par manque de temps. Je salue le succès et les superbes slides du projet! (ainsi que la demo en video)

Félicitations!

Voir le forum: Actualités

4 réponse par metagoto

(2 réponses, posts Actualités)

J'attends le .314 big_smile

Voir le forum: Actualités

5 réponse par metagoto

(87 réponses, posts Actualités)

A mon avis, il faudrait que xyl supporte un "mode" qui ne force pas d'inclusion de css (ni même de js). Dans un tel "mode", ça serait à l'utilisateur de gérer lui même les fichiers à inclure.
Comme l'a dit jojolapine, l'utilisateur a souvent besoin/préfère packer ses fichiers, les minifier etc (ainsi que d'utiliser une autre version plus récente/ancienne de la librairie js).

Je ne connais pas très bien mootools (c'est un euphémisme). Si Hoa customize cette librairie, alors il faudrait que cela soit fait de manière modulaire (je pense que c'est ce que tu veux faire), pour que toute les additions spécifiques à Hoa soient ajoutées "au dessus" de la librairie, sans toucher aux sources officielles. Dans le "mode libre", l'url de la librairie est laissé au choix de l'utilisateur (url de mootools ainsi que l'url des trucs spécifiques à Hoa).

Ensuite, rien n'interdirait de permettre à xyl de spécifier les urls des resources.. par composants ou.. bref, le problème reste entier wink
Ca serait le mode "clé en main".
Dans un cas on ignore le resource="" (mode libre) et dans l'autre on se débrouille le prendre en compte (mode "clé en main").

L'important est que chaque composants nécessitant des resources particulières soit correctement documenté à ce sujet. Tel composant nécessite telle librairies et tel type de css etc.

Pour le script qui packe des css ou js entre eux, ça pourrait aussi être un controller fournit par le framework.

Voir le forum: Actualités

6 réponse par metagoto

(87 réponses, posts Actualités)

Il me semble que les libraries UI (css/js) proposent souvent une sorte de fichier core.css qui contient les "fondations" sur lesquelles les différents composants/widgets s'appuient.
Ensuite, des "themes" interchangeables réunissent tout ce qui est nécessaire dans un seul fichier css. Ces themes contiennent donc des portions qui ne sont pas forcément utilisées (par exemple l'utilisateur n'utilise pas de "tab widget" même si son fichier theme comporte une section pour ce genre de widget).
Sur les sites web de ces libraries, il est parfois possible de construire puis télécharger des themes qui inclus ou exclus certaines parties non souhaitée (genre pas de portion pour les tab widgets).

Pour le js, c'est un peu la même chose. La partie "core" est une library parfois indépendante et à usage généraliste. La logique js pour les widgets est présente dans un seul fichier js annexe. Au final ça fait 4 fichiers à inclure (2 css et 2 js), sans parler des "addons" qui peuvent fournir leur propres js et css. Packer ses fichiers en un seul (ou 1 css et 1 js) est fait par l'utilisateur ou par des services présents sur le site de la librairie.

A mon avis, tu pourrais partir sur quelque chose de "simple" comme décrit juste au dessus (en tout cas pour commencer). Dès que le user utilise un des éléments spéciaux de hoa html, alors il insert les quelques fichiers css et js nécessaires.
Si les css sont claires et bien ordonnés/construits, il doit être possible de facilement se constituer ses propres fichiers contenant le minimum d'information (pour les users qui savent ce qu'ils font).

Le fw pourrait proposer un service/system pour packer de lui même plusieurs fichiers css et/ou js en un. Du genre css.php?a.css,b.css,c.css (truc qui se fait un peu partout). Un tel système serait indépendant de xyl.

Voir le forum: Actualités

7 réponse par metagoto

(87 réponses, posts Actualités)

+1 jojolapine

Dans la video, le ns de xyl m'a l'air bien classique (austère??)
Tu ne devais pas utiliser un ns un peu plus funky?

ns = namespace

Voir le forum: Actualités

8 réponse par metagoto

(22 réponses, posts Actualités)

Hywan a écrit:

Entre un resolveur qui a une méthode resolve() ou une classe enfant qui implémente resolve(), tu vois quelle différence ?

Une différence fondamentale! big_smile
Comme on a vu et débattu, maintenant un certain nombre de fois, nos divergences peuvent se résumer à des considérations "OOP" (j'allais dire de "base", mais ça prete à confusion;) usuelles et communes. Qu'est-ce qui hérite de quoi, qu'est-ce qui agrège quoi, qui est responsable de quoi etc.

L'essentiel est que ça fonctionne et que tu sois satisfait (que je résume en "ça fait son job").

Voir le forum: Actualités

9 réponse par metagoto

(22 réponses, posts Actualités)

Hywan a écrit:

Si j'ai un dispatcher abstrait, ce n'est pas pour faire du raffinement (de l'héritage). Je pense que c'est justifié d'avoir un resolver/dispatcher abstrait qui mâche le travail pour ses enfants. Note qu'il ne fait rien à part dispatch() et resolve(). Il s'occupe aussi des paramètres et permet de savoir si on a un appel asynchrone ; c'est tout. On ne va donc pas raffiner des masses, on va surtout créer. Vois le comme une interface enrichie . J'ai juste supprimé des couches intermédiaires si tu veux.

"on va surtout créer" est une des raisons pour lesquelles je préfèrerai composer avec des resolvers plutôt qu'hériter d'un dispatcher, fusse-t-il abstrait. Ce qui n'empêche pas d'ailleurs de dériver du dispatcher si vraiment on veux le raffiner, mais ça resterait orthogonal par rapport aux resolvers.

Hywan a écrit:

Ton avant dernier paragraphe résume bien ce que j'ai fait. Es-tu d'accord avec ce que tu as écrit  ?

Oui

Hywan a écrit:

Je suis d'accord que ce n'est pas la meilleure façon de le faire, mais je vais t'expliquer pourquoi je supprime des intermédiaires et des couches. C'est pour une raison simple : les performances. Le code actuel est aussi souple et bien encadré que si on avait les autres couches (une « vraie » interface Hoa_Controller_Resolvable par exemple, avec ses enfants), sauf qu'il y a moins d'accès disque car moins de fichiers. Même si l'architecture paraît moins puissante en la regardant au premier abord, ça reste quand même tout aussi puissant (à moins que j'ai râté quelque chose ?).

D'accord pour supprimer les accès disque. C'est d'ailleurs pour ça qu'il y a APC ou l'autoloading ou le fait de mettre plusieurs classes interdépendantes dans un même fichier.
Dispatcher abstrait + concret c'est 2 fichiers. Dispatcher + resolver c'est toujours 2 fichiers.
Les interfaces: si ça ne tenait qu'à moi, il n'y en aurait pas, en tout cas pas pour les resolvers. Actuellement, un resolver pourrait se contenter d'être un simple callable: une func (anonyme) ou un objet qui implémente __invoke().

Je reconnais que ce point de vue est assez marqué: aller vers plus de "duck typing", ce qui est en contradiction par rapport à beaucoup de projets qui s'appuient sur toujours plus d'interfaces et de hierarchies.

Pour un projet comme hoa, faut-il sacrifier un design "correct" pour gagner quelques accès disque? Je ne dis pas que ton design n'est pas bon, juste que à mon sens, en condition de prod avec APC, les problèmes de fichiers sont moindres. Avoir un design satisfaisant passe en priorité (ce qui ne veut pas dire qu'on peut exploser le nombre de classes/interfaces etc)

Voir le forum: Actualités

10 réponse par metagoto

(22 réponses, posts Actualités)

Oui pour des paramètres dans le dispatcher abstrait et d'autres dans les concrets.
Après, je ne sais pas si, par exemple ceci:
'synchronous.controller'  => '(:controller:U:)Controller'
devrait être stipulé dans le dispatcher abstrait. Ca me parait trop "concret" wink (trop spécifique à un mode de résolution)
Je suis d'accord qu'on peut choisir des paramètres "default" et qu'il faut donc faire un choix à un moment donné.

Je ne l'ai pas noté jusqu'à maintenant, mais il faudrait que Array $parameters dans le constructeur du dispatcher abstrait soit effectivement pris en compte, car cet argument est ignoré pour l'instant.

L'essentiel c'est quand même que toi tu sois satisfait! Je me contente de critiquer, à peu près constructivement je l'espère, mais ça reste juste mon avis sur ce que m'inspire ton travail.

Je reste un peu dubitatif par rapport à $r->route()->dispatch();
C'est un peu comme si le router s'octroyait les responsabilités du dispatcher.

Je me dis que au lieu de faire $r->addDispatcher(), on pourrait faire $r->addResolver(). Ca me parait plus "propre".
Le dispatcher garde la responsabilité de dispatcher, soit à partir de son resolver par défaut, soit à partir du resolver passé par la rule.
Ca voudrait dire que les resolvers seraient des entités à part entière, et non pas des "raffinements" de dispatchers abstraits. Cela reste dans la ligné de mes précédents posts, à savoir privilégier la composition plutôt que l'héritage pour les dispatchers.

Le dispatcher reste minimal et générique pour la majeur partie des usages. Son interface ne change pas. Les trucs spécifiques de "resolutions", qui sont les plus à même de changer d'appli en appli et/ou au sein même d'une appli (moins fréquent) sont factorisés dans les resolvers. Le fw privilégie un resolver standard (Basic) qui est suffisant pour beaucoup d'usages ainsi que correctement équipé en terme de vérification, report d'erreur etc. Ca me parait être un bon compromis et un beau projet.

Les détails d'implémentation et certains choix vont changer par rapport à ce que je ferai, mais ne peut-on pas dire que ton code supporte déjà ce que j'ai résumé juste au dessus?

Voir le forum: Actualités