Bien le bonsoir

L'idée me tarraude depuis longtemps (l'unité de base, c'est l'année…), mais elle me paraît assez novatrice pour que peu n'aient eu le cran d'essayer de la lancer.
Posons la problématique :
Actuellement, il y a des tonnes de frameworks pour ceci et pour cela, on ne peut pas dire que quelquechose n'est pas possible sur le net (à part commander sa cafetière (et encore, il y a des cafetières usb ) ), nous ne sommes plus limités que par notre imagination.
De même, niveau performances, avec les machines modernes, c'est un critère qui est de moins en moins prépondérant dans le développement web. Et de toute facon, il est toujours possible d'optimiser.
Parallèlement à cela, on voit se multiplier les incompatibités, tel framework étant incompatible avec tel autre, telle base de donnée ne supportant pas le standard SQL, ...
Ainsi que des incompatibilités entre son CMS et son forum, ou son blog, son chat, …
Et pour ma part, concernant les forums que je connais très bien, j'ai le sentiment qu'ils manquent de modularité, car oui, c'est bien gentil, phpBB a des modules, qu'on peut installer sans trop de problèmes (attention, après 3 mods, c'est mort) avec EasyMod par exemple, mais lorsque vous installez un logiciel sur votre ordinateur, on vous demande d'aller modifier le kernel.dll ou bien le schost.dll ?
Quant aux CMS, la modularité est un peu plus présente, mais ce n'est pas encore cela, par exemple, Joomla qui a un certain modèle de templates, mais je pense que ce n'est pas à l'équipe de Joomla de décider ce que l'on veut comme moteur de templates.

Le problème n'est donc l'occurence n'est plus technique, mais complètement architectural et conceptuel. L'idée qui m'est venue était alors de concevoir un noyau qui serait à la base de nombreux projets. Le noyau permettrait de la même manière qu'un noyau d'OS d'allier modularité à compatibilité, mais aussi transparence, et éventuellement sécurité. Ce sont les maîtres mots de mon idée.
Niveau modularité, le système pourrait faire fonctionner avec le strict nécessaire, et ne charger que ce dont l'application aurait besoin.
Niveau compatibilité, tous les modules seraient basés sur un système commun, et donc par exemple, on pourrait intégrer un chat dans un forum, sans avoir à modifier une ligne de code.
Niveau transparence, c'est un des points le plus important, il est absolument indispensable que la sortie puisse se faire indifféremment de ce qu'elle va devenir, c'est à dire pouvoir envoyer la sortie aussi bien vers un mail, que vers un module ajax, ou encore un fichier. De même, permettre tout aussi bien l'utilisation de smarty que de phpLib, ou une syntaxe type php pour les templates. Ainsi que permettre l'utilisation de n'importe quelle base de données avec un vrai mécanisme de transparence, car en l'occurence PDO c'est bien joli, mais on ne peut pas envoyer la requète sans faire attention à ce qui va la lire et l'exécuter.
Enfin, cette voie ouvrirait le chemin à d'autres perspectives comme la notion de dépendances entre les modules, d'événements provoqués par les modules, ainsi que la possiblité d'intégrer au noyau des fonctions de débuggage et de contrôle.

J'ai fait de très nombreux jets de cette idée, toujours plus aboutis, le dernier consistait en un noyau regroupant le strict minimum, et avec des modules noyaux intégrés à celui ci permettant d'activer ou de désactiver certains fonctionnalités comme la gestion des tableaux multiglobaux (en gros, celui là vidait le contenu des tableaux), des événements (exécution de tel module ou telle fonction, …), dépendances, gestion des erreurs, débuggage (tracage complet de toutes l'exécution), autorisations (intermodulaires), avec une sorte de shell dont je n'ai jamais réussi à faire une version satisfaisante.
Le principal travail pour cette architecture là étant de définir ce qui doit être mis dans les modules du noyau, c'est à dire qu'est ce qui ne peut être gérer que par ca, ou bien qui est vraiment trop critique pour ne pas être intégré au noyau, de quoi le noyau a besoin et qu'il serait dommageable de charger plus tard. L'idée étant aussi de permettre à n'importe qui d'utiliser le noyau sans base de données, ou bien pouvoir l'utiliser pour autre chose que pour renvoyer du texte au navigateur.
Et la transparence est aussi un challenge architectural, car il faut trouver la manière de regroupper les modules ou les fonctions qui font la même chose, sans pour autant les brider…

Voilà pour mon idée, qu'en pensez vous ?
Pour ma part, je pense que le web gagnerait beaucoup à se rationnaliser de cette manière, les outils regrouppant les frameworks (comme ce qu'à fait Zend) ne seraient plus forcément utiles, et le développement serait simplifié…

Salut

J'ai également ce genre de réflexions qui me trottent dans la tête depuis un moment.

L'idée principale si je comprends bien, est de faire un noyau polymorphe. Je trouve souvent mon inspiration dans la biologie (étendue à la chimie, ça va de soit). Pourquoi ? La biologie n'a pas de limites dans l'architecture, et les intéractions entre les éléments. Je m'explique. Si on devait schématiser le fonctionnement général (je schématise beaucoup, et oriente la pensée au passage), on aurait un corp A. Ce corp va avoir une intéraction avec un corp B. Pour que cette intéraction se fasse bien, le corp A se loge à un endroit spécifique de B. Une réaction chimie se réalise alors, et va engendrer de nouvelles intéractions, de plus en plus petites. Toutes ces intéractions sont liées par des « corps vecteurs », qui sont le plus souvent des molécules. Donc, une transformation est une chaîne de réactions chimiques qui vont réagir à un moment spécifique, à un lieu spécifique, avec des réactifs spécifiques.

Quel est le rapport avec la programmation ? On a un noyau. Ce noyau doit pouvoir être polymorphe. Les causes du changement de formes vont être extérieures. Un module, un objet, une méthode vont vouloir intéragir avec le noyau. On ne doit donc pas intéragir directement. Je pense qu'on doit faire une sorte de membrane à ce noyau. Cette membrane serait constituée de pleins de corps vecteurs qui vont orienter les transformations et donc les intéractions. Une membrane est également constituée de plusieurs couches. On aurait donc des couches qui serviraient à filtrer, pour faire le lien avec la sécurité.

La chimie suit des règles précises. La biologie également. Tout système stable met en place et subit ces propres règles. C'est ce qui permet une très grande modularité. Impossible de reconstituer le comportement biologique en informatique. Surtout en PHP, je pense que le langage n'est pas capable de faire ça. Mais l'idée est là. Pour qu'un système soit stable, il doit être soumit à certaines règles. Ces règles doivent être simplistes à l'extrême de façon à assurer la modularité, mais elles doivent également être suffisament larges pour assurer une flexibilité. On peut prendre pour exemple l'ADN. 4 lettres pour une infinité de combinaisons (biologiquement parlant ). Les corps vecteurs devraient être regrouper en famille (différent niveaux d'exécution par famille).

Le MVC est un peu dans cette philosophie. On a 3 couches, et on regarde le comportement du contrôleur. Le contrôleur ne sait rien ni du modèle, ni de la vue. Et pourtant, il fait le lien. Car il y a des règles qu'on a mise en place. Ces règles permettent l'intéraction (et a fortiori la communication) entre ces couches.

Il existe une hypothèse en biologie qui s'appelle Gaïa. C'est une hypothèse qui considère la Terre comme un être vivant, et non pas comme une planète : un corp "inerte". C'est ultra intéressant car on peut expliquer chaque chose avec cette hypothèse. C'est systématique. On retrouve le concept mis en place dans ce que je viens de vous expliquer. Chaque intéraction est une chaîne de sous-intéractions, qui est également une chaîne de sous-sous-intéractions ... n-sous-intéractions, jusqu'à arriver à un changement. C'est tout bêtement le principe du Framework. Je dois vérifier, mais une fois Cyrano m'a dit qu'on atomisait un programme. Il faut comprendre qu'on le sépare en briques, de plus en plus petites, jusqu'à devenir complètement abstraite, sans aucun but, sans aucune direction/orientation. Et en biologie, si on regarde une maillon d'une chaîne de réactions, il n'a aucun sens. Mais si on le place dans un contexte particulier, il prend tout son sens. Le but serait alors de faire en sorte que chaque maillon soit polymorphe.

Je pense que c'est la piste à suivre. Il faut définir des règles élémentaires. Puis faire des corps vecteurs, i.e. des briques du programmes qui sont complètements abstraites et polymorphes. En utilisant ces briques pour construire une chaîne, cette chaîne pourrait prendre plusieurs formes, elle serait polymorphe. On pourrait même penser à ne pas avoir de noyau. Le système serait suffisant à lui-même. Mais je doute qu'on puisse enlever le noyau, car son rôle pourrait bien être de définir les règles et de vérifier leur respect.

Voilà, c'était un peu long et très abstrait, mais c'est une idée. J'espère que vous vous êtes pas endormis et que vous avez compris quelque chose

Je n'ai pas absolument tout compris dans ton post, mais il y a un point sur lequel j'ai tilté et auquel j'adhère totalement, c'est la nécessité de subdiviser tout. C'est ce qui peut permettre une très grande modularité, car par exemple, permettre de choisir quel module s'occuperait de gérer le formulaire de post dans un forum, ce serait vraiment puissant comme fonctionnalité.

Tient je sens qu'un groupe de travaille est en train de se former ...

Dans un premier temps, je ne pense pas qu'il faille réfléchir sur des choses concrètes.

A mon avis, il faut abstraire au maximum les choses. Plus on abstrait les briques (ce que j'ai appelé corps vecteurs), plus elles seront abstaites. Elles vont se rendrent abstraites d'elle-même en fait. Pour prendre un exemple, tu subdivises ton programme. Plus tu le subdivises, et plus les briques vont être réutilisables dans d'autres contextes. C'est à cette idée que tend les frameworks à mon avis. Et c'est vers cette idée qu'il faut tendre.

Ensuite, pour le bon fonctionnement de ces briques, dites corps vecteurs, il faut établir des règles. Et c'est là-dessus qu'il faut plencher. C'est la plus grosse partie du travail à mon avis. Ces règles vont définir la logique d'interactions de ces corps vecteurs entre eux. En gros, définir leur comportement. Il faut que les données entrantes et sortantes aient des formes précises, que l'on exploitera avec d'autres corps qui vont retravailler les données, et les renvoyer etc. C'est comme ça que fonctionne les programmes bien conçus en somme ! Je n'invente rien. Mais il faut pousser le raisonnement à l'extrême, et là, on arrivera à un système architectural polymorphe articulé autour d'un noyau composés de ces dits corps vecteurs.

Tu comprends mieux ?

PS : abstraire est un synonyme d'isoler. Ne pas confondre avec abstrait !

Voir la programmation orienté aspects ça peut vous intéresser.

Sinon les frameworks modernes (j'ai symfony en tête car j'ai 4 projets l'utilisant en cours de dév actuellement) respectent tous ce concept : le framework propose un ensemble de classes génériques, qui généralement ne sont que des wrappers.
- sfMail est un wrapper de PHPMailer qui peut être remplacé par n'importe quel mailer, sans rien changer au code principal de l'application.
- sfView est un wrapper de… PHP (à la Savant) qui peut reposer aussi bien sur PHPLib que Smarty, et cela ne changera strictement rien à la syntaxe des actions.
- Les modèles sont générés automatiquement à partir du schéma selon l'outil d'ORM que l'on souhaite (Propel, Doctrine, ezPdo…).
Et toute contribution reposant sur un outil défini doit respecter ce principe, par exemple si j'utilise JpGraph pour faire une class sfCaptcha, il faudra qu'il soit possible de remplacer JpGraph par Cryptographp aisément (en fait, c'est le cas ).

Le principe de modularité il est bien gentil, tout le monde est pour, mais je m'attendais plus à ce que tu présentes une idée originale d'implémentation. Parce que là telle quelle, ton idée ne révolutionne rien du tout
Pour appliquer le principe de modularité, il faut se baser sur des wrappers. Ça c'est fait, qu'apporter de neuf donc ?

Quant à ton idée de «corps vecteurs», on pourrait appeller ça SOAP et les web services non ?

Je pense au contraire qu'il faut refléchir dès maintenant dans le concret, parce qu'on n'arrive rarement à quelque chose en partant sur des principes aussi génériques. Puisqu'au final quand on a notre belle théorie sur papier, dès qu'il s'agit de l'implémenter on se casse les dents ou on finit par refaire ce qui existe déjà. En refléchissant concrètement dès maintenant à comment tu vois l'utilisation de ton framework, tu éclairciras bien les choses déjà, et peut-être mettras-tu à la lumière les vraies innovations que tu veux apporter.

Le tout sans sombrer dans l'usine à gaz absolue et inutilisable (genre si pour appeler une méthode il faut que j'écrive une dizaine de lignes en XML, uark).

Chais pas, en vous lisant là comme ça, je pense directement au Zend Framework.
J'ai tort ?

@Icebreak : ZF oriente beaucoup tes actions. Et ZF a des manques, il ne faut pas glorifier ZF à tout pris car c'est Zend, IBM etc. ZF a des erreurs dans certains packages comme tous les Framework. Pour illustrer mes propos, regardes le package Uri Http, ils se basent sur la RFC 2396, qui a été mise obselète par la 3986. Ce sont des petits détails, mais ça montre qu'il ne faut pas élever ZF au rang de Framework absolu qui vient sauver la vie à des milliers de pauvres programmeurs en détresse. ZF est un excellent travail, bourré de bonnes conceptions.

Et avec ça que je fais la transition vers Naholyr. Si on voudrait faire quelque chose de réellement modulable, il faut multiplier les couches. J'entends par là, pour les emails j'ai fais de cette façon : On créé une instance de Mail, qui va en créer une de Mime pour créer le mail. Ensuite, on utilise le design pattern Factory puis Strategy pour utiliser de Transport que l'on souhaite. Le transport choisit étend la classe abstraite, qui est chargée de contenir des méthodes abstraites, de préparer la forme des données que va recevoir le transport.
Le constructeur du transport va appeler son homologue Protocol qui va aussi étendre une clase protocol abstraite pour créer la connexion si nécessaire. Cette connexion est donnée par un autre package (Socket) qui gère les flux de données : envoie et lecture.

Le fait d'utiliser autant de couches permet :

• - d'embrouiller son adversaire ^^ (blague à part, si on connait les designs patterns, ça ne pose pas de soucis) ;
  - à aucun moment dans ma classe transport SMTP je n'utilise les commandes SMTP telles quelles, je passe toujours par des méthodes ;
  - donc, pour une question de maintenance, je me simplifie grandement la vie ;
  - et on reste dans le DRY (Don't Repeat Yourself) car chaque objet sera utiliser plusieurs fois, mais on aura un unique objet.

Et ça rejoint ce que je disais, des petites briques. On ne peut rien faire du protocole SMTP tout seul, pourtant si on le couple avec le Mail/Mime/Transport, on peut envoyer un mail. Il ne faut pas penser : faire un package pour envoyer un mail par SMTP, mais penser : faire un package SMTP pour exécuter des commandes SMTP, et on utilisera ce package dans un certain contexte pour envoyer des mails (bon c'est un mauvais exemple, car on ne peut qu'envoyer des mails avec SMTP ^^, mais le principe est là). De façon à pouvoir réutiliser ce package dans une autre contexte.

C'est pas évident, je vous l'accorde. On va multiplier les fichiers, et tout le monde n'est pas fan. Mais si c'est gérer correctement, il n'y a pas tellement de problèmes.

Une dernière chose : et si on faisait un système avec une IA (Intelligence Artificielle), c'est à dire qu'il serait capable de savoir ce qu'il doit faire tout seul. Bon, ce serait presque de la science-fiction, et surtout : je ne connais rien en IA. J'imagine que faire un système qui doit apprendre est compliqué (ah bon ? ), mais si on arrive à faire ça, ce serait pas trop mal hehe.

Pour conclure, de toute évidence il faut forcer sur les designs patterns qui sont une bonne issue à notre problème. Mais il n'y a pas que ça. Tu parlais de wrapper, je pense qu'il faut également les multiplier. Le wrapper est une bonne image pour illustrer ce que j'ai fais avec mon package Mail. On englobe/rappatrie différent package qui n'ont pas de sens seul, mais englober ensemble, ils en ont un.

PS : au passage, corps vecteurs est bien ronflant comme terme ^^, mais ce sont juste les wrappers je pense.

Oui enfin toujours pareil, tout ça, ça existe déjà et c'est fait de manière pragmatique et très utilisable, genre

$mail = new sfMail();
$mail->setSMTP($host, $port); // Je choisis mon mode de transport (transport)
$mail->setBody($body); // Je crée mon message (mime)
$mail->attachImage($path, $cid); // J'attache une image que je peux utiliser dans mon corps HTML, avec la syntaxe CID:###
$mail->send(); // J'envoie

Dans tout ça je suis libre d'utiliser PHPMailer qui est assez monobloc, ou bien d'utiliser une autre couche qui elle aura fait le choix de se séparer en une couche Mime, une couche Transport, etc…

J'ai l'air de vouloir à tous prix casser ton élan comme ça, mais il ne faut pas le prendre comme ça hein C'est juste que j'essaie de gratter le plus loin possible pour te pousser à nous montrer ce qui est vraiment innovant dans ton système.
En revanche il se peut qu'à force de gratter j'arrive à la conclusion qui s'impose assez souvent dans ce genre de projet : tu devrais plutôt réécrire des modules utilisables par des frameworks existant qui sont déjà très bien pensés et supportés Pour reprendre notre exemple précédent : si tu écrivais un beau package "Mail" multi-couche il serait aisé de le proposer en plugin de symfony, en addon de copix, etc… Dès qu'un système est multi-couche il est de fait très configurable, et donc très apprécié en tant que plugin de frameworks (je pense notamment à wikirenderer). Mais de là à faire un framework dont le noyau est sur ce modèle, je ne suis pas convaincu que ce soit viable.


Pour le ZF en effet ce n'est pas la panacée, il y a pas mal de choses qui sont très discutables, et ce qui m'a vraiment rebuté c'est cette obligation d'avoir de l'url-rewriting pour utiliser leur système MVC. Alors que tous les frameworks MVC sérieux supportent le PATH_INFO, et que c'est extrèmement simple à mettre en place (pour peu que le framework soit bien séparé en couches dont une couche de gestion d'URI), j'ai trouvé que ça ne faisait pas sérieux.


Enfin pour le système de fichier intelligent, tu balances ça mais tu ne donnes aucun indice sur la question humaine par excellence : pourquoi ?

Haha Oui ça me donne pas mal l'impression que tu veuilles me casser !
Non, plus sérieusement, je ne donne que des idées. Faire un modèle architectural comme je le décris plus haut me paraît extrêmement compliqué, mais très intéressant. Il faut gratter pour trouver une nouvelle façon de penser les architectures.

L'inconvénient quand tu veux implémenter un module à la place d'un autre, c'est qu'il faut tout de même réécrire un petit quelque chose. Alors que si on sépare vraiment en tout petit bloque, on aura pas ce problème. C'était l'idée.

Pour l'IA, je n'ai aucune idée lol. C'était pour faire une ouverture comme on dit chez les littéraires, histoire de faire rêver .

Si on devait avoir une révolution en programmation Web, qu'est-ce que tu en attendrais ? Comment tu l'imaginerais ?

Je n'aime ni ZF, ni Symfony pour être direct. Enfin, j'admets que ZF est vraiment très bien conçu, et que j'ai beaucoup appris en lisant les sources. En revanche, Symfony me paraît plus désordonné. Je n'aime pas les sources, elles ne m'attirent pas. A l'instart de ZF qui me paraît plus propre et plus ordonné, on sent le professionnalisme et l'expérience. Et je n'arrive pas à retrouver ça dans Symfony. Quitte à choisir, je prendrais donc ZF. Mais pas grand rapport avec le sujet lancé par Sékiltoyai

je plussoie naholyr :
il faut une approche pragmatique, qui utilise des outils éprouvés ( ORM, templates, ... ) et symfony et les frameworks aussi évolués constituent cette approche.

ton projet servirait à quoi ? développer des sites de manière "générique" ? c'est ce qui est faisable via les frameworks...

A+

Pascal

Comme pascaltje, je plussoie Naholyr.

C'est déjà ce qui est en place dans ma société et nous en sommes très content.

Nous avons un Framework propriétaire qui consiste en une suite de classe qui ne sont que des sur-couche d'autres modules.
L'exemple de plus récent, c'est le changement de fournisseur de paiement online. A part la classe du framework, rien n'a été modifié et les codes fonctionnent encore.

Je ne dis pas le contraire

Sékiltoyai émettait une hypothèse, j'ai juste donné mon opinion . J'ai conscience que les systèmes existants sont très orientés dans cette philosophie, et je n'ai pas de projet en particulier qui révolutionnerait le milieu . J'avais juste lancer une idée qui allait dans le même sens. Mais je m'imaginais un système encore plus souple, et encore plus viable.

Ce qui serait intéressant, ce serait d'explorer de nouvelles pistes dans la façon de concevoir un programme. Peut être que si on creuse dans toutes les directions, on finirait par trouver quelque chose de sympa, je sais pas moi. On peut chercher .

Sur ce, je vous laisse. Je pars en Laponie mercredi pour 1 mois. Le clavier aura à peine le temps de refroidir . On se revoit en septembre avec de nouveaux problèmes à résoudre .

Bon, je vais essayer de clarifier cela bientôt parce que la différence qui me paraît nette ne l'est pas pour tout le monde. J'amènerais des exemples

Je suis actuellement en train de travailler sur symfony c'est vrai qu'il est très bien pensé et largement modifiable et implémentable

Cette structure en noyau que tu veux faire en fait je n'arrive pas à voir ça pour des applications web je trouve que le modèle le plus approprié et par exemple comme le pense naho l'approche de symfony mais je ne glorifie pas ce framework il est bien pensé. Apres niveau perf c'est autre chose mais là c'est un maniac du ms qui parle ( un Hubert 2 )