Bonjour,

Je jet une ancienne idée dans la discussion ici. Ca me rappel à la discussion suivante:
http://www.phpfrance.com/forums/voir_sujet-30330.php

Je travail depuis un bon but de temps sur un système dans le quel beaucoup de problème qui ont été discuter ici sont résolu d'une manière simple mais inconventionnellement.

Le but était un système qui permet d'être flexible et de réduire en même temps la complexité. Le problème à résoudre était à construire un interface par lequel les couches (mvc) peuvent communiquer entre elles. Cet interface devrait être:

• abstrait
  simple
  garantir une indépendance maximale.

Le système est complètement programmer en objet, mais l'utilisation de l'interface se montre fonctionnel. On n'a rien avoir avec les méthodes des classes du modèle. On ne sais même pas de quelles et de combien méthodes une classe d'action se compose. Pour donnée un exemple du code email déjà poster ici.

$model->action('common', 'sendmail',
               array('error' => & $error,
                     'host'   => '',
                     'sendto' => '',
                     'from'   => '',
                     'body'   => '',
                     ..etc...) );

Le système s'occupe à inclure la classe d'action (ici du module 'common'), et exécute deux méthodes principal qui se retrouvent dans tous les classes d'action.

1. validate() qui fait une validation des paramétres de l'array
2. perform() qui fait le boulot principal

Même pas besoin à enregistrer les classes d'action. Il faut juste les placées dans le répertoire du modèle pour de suite les utiliser depuis n'importe quel point du système (évidemment pas dans les squelettes html). On peu même appeler depuis une action d'autres actions du modèle. De cette façon on peut composer un bloc (Lego) d'actions qui peuvent ensemble traiter des demandes très complexe.

Donc on traite les actions du modèle comme une black box. On ne sais rien de se qui se passe dedans. On sait seulement se qu'il faut alimenter pour recevoir un résultat. L'interface se montre toujours de la même façon et c'est la seule façon comment les couches (controller -> model ou model -> model) peuvent communiquez entre elles..

Pour en savoir plus:
http://www.open-publisher.net
La documentation:
http://www.smart3.org/Open_Publisher.pdf

Je cherche toujours des développeurs pour améliorer ou discuter la conception.

Armand

p.s.
Juste une remarque concernant la comparaison de programmation et la biologie de HyWaN .
Une synapse ne sais rien de son environnement. Elle envoie et reçoit des informations à et par des synapse qui la contourne. Le cerveau ne se met pas dans un état tilt si une synapse envoi une information qui abouti nulle part. Le cerveau en tout fonctione même si il est endommager.

Personnellement je ne crois pas que la programmation objet à quelque chose avoir avec la façon comment la pensée humaine fonctionne. Dans beaucoup de livre de programmation c'est la première leçon qui nous montre la relation entre ce gendre de programmation en objet et la pensée humaine.

Bon, j'ai trouvé le temps de répondre.
Je pense que vous n'avez pas vu la subtilité de l'idée. Car mon idée est peut être proche des concepts de framework mais dans la philosophie, les deux sont assez lointains.
C'est à dire que j'ai l'impression que vous êtes centrés sur le développement, le programmeur. Vous voulez donner au développeur le maximum d'outils pour faire ce qu'il veut faire. Mais en l'occurence, on développe pour un utilisateur final, pas pour nous.

Pour comprendre le concept de “noyau web”, il faut vraiment que vous fassiez l'analogie avec un système d'exploitation. C'est à dire que c'est tout d'abord l'utilisateur qui fait l'action d'installer le système puis ensuite les modules qu'il désire avoir sur son système (par des outils bien entendu), sachant que les modules sont totalement indépendants du projet, et que seul le noyau est requis pour faire fonctionner l'ensemble. Et lorsqu'un développeur veut développer une application sur ce système, il ne sait pas sur quel environnement cela va s'exécuter, il a juste besoin d'un module qui fait ceci, un autre qui fait cela, et c'est le noyau, lors de l'exécution, qui va se charger de faire tout cela pour lui. Au final, on doit obtenir un système tel que l'on puisse, d'un point de vue macroscopique, exécuter une application simplement avec une ligne de commande genre :

load_module machin at 56px,47px SQL=SQLite SRC=post

(Après, c'est selon le langage codé derrière)
ou bien d'un point de vue microscopique, dans un module :

create_link msg/error.txt MOD=trucmuche

Ou plein d'autres joyeusetés du style.

Et là où c'est différent d'un framework, du moins à mon avis, c'est que pour un noyau, déjà, toute application est un module, pouvant être utilisé par d'autres modules, et on code son module pour le noyau, en acceptant de n'avoir aucun contrôle sur autre chose que sur son module. Pour un framework, la philosophie est inverse, on crée son application autour du framework, on peut très bien contrôler le framework, car c'est l'application qui définit l'environnement, ainsi que les interactions entre les différents modules du framework. Dans les frameworks, l'application a un rôle central et n'est pas un module du framework.
Ensuite, pour un noyau, on installe son module sur le noyau, alors que pour les framework, on livre Application+Framework dans un package complet.
Enfin, à ce que je crois, les frameworks semblent avoir des modules définis, c'est à dire qu'ils sont livrés avec des modules de base, et dans tous les cas, c'est au développeur de choisir les modules qu'il utilise, alors que dans le cadre d'un noyau, là encore le système est livré simplement avec le noyau (ou bien des modules natifs non nécessaires et remplaçables par d'autres modules si ca nous plaît pas, du genre l'administration est fournie, mais pourquoi imposer une interface d'administration ? Pourquoi l'utilisateur n'aurait pas le droit d'en changer ?), l'utilisateur choisit ensuite les modules qu'il veut installer pour son système, et quel module utilisera tel module.

Bref, c'est là le principal concept, c'est le fait que l'utilisateur doit avoir un contrôle total de son environnement, et ce, en plus des principes nécessaires de transparence, de modularité, d'interconnectivité (deux applications doivent pouvoir utiliser le même système d'utilisateurs par exemple, et pouvoir être affichées sur la même page, sans conflit), de sécurité, et j'en oublie.

Je posterais bientôt l'architecture que j'ai pensé.

C'est à dire que j'ai l'impression que vous êtes centrés sur le développement, le programmeur. Vous voulez donner au développeur le maximum d'outils pour faire ce qu'il veut faire. Mais en l'occurence, on développe pour un utilisateur final, pas pour nous.

Mais l'utilisateur final a-t-il besoin d'un tel outil ?
Il ouvre un skyblog, si vraiment....

$model->action('common', 'sendmail',
               array('error' => & $error,
                     'host'   => '',
                     'sendto' => '',
                     'from'   => '',
                     'body'   => '',
                     ..etc...) );

Le système s'occupe à inclure la classe d'action (ici du module 'common'), et exécute deux méthodes principal qui se retrouvent dans tous les classes d'action.

En même temps, ça ou un simple __autoload() et un très lisible

Model_Common::sendmail(array('error' => & $error,
                     'host'   => '',
                     'sendto' => '',
                     'from'   => '',
                     'body'   => '',
                     ..etc...) )

C'est strictement identique, mais plus lisible, plus facile à gérer, et ça fait moins usine à gaz

Apres niveau perf c'est autre chose mais là c'est un maniac du ms qui parle ( un Hubert 2 )

Après tests de montée en charge sur un site que l'on vient de mettre en production, je suis très satisfait des perfs. Il faut bien penser qu'il y a des paramètres spécifiques à mettre en route en prod : limiter la quantité de logs, mettre en cache, supprimer le mode debug.

Rien qu'avec ça on a un rapport de 1 à 100 en terme de perfs par rapport au serveur de dev

C'est à dire que j'ai l'impression que vous êtes centrés sur le développement, le programmeur. Vous voulez donner au développeur le maximum d'outils pour faire ce qu'il veut faire. Mais en l'occurence, on développe pour un utilisateur final, pas pour nous.

Mais l'utilisateur final a-t-il besoin d'un tel outil ?
Il ouvre un skyblog, si vraiment....

Bah, pour moi, si. Il y a vraiment un manque.
Si on peut faire plus, je ne vois pas pourquoi on ne le ferait pas. Si jamais plus tard, l'utilisateur a cela, il ne comprendra pas comment il a pu s'en passer avant. Si on dit tjs “l'utilisateur n'en a pas besoin donc on ne fait pas”, on n'avance jamais. Le but n'est pas de fournir une fonctionnalité absolument indispensable à l'utilisateur, mais permettre enfin :
-A l'utilisateur de modeler comme il le souhaite son site web, plus de contrôle, donc une grosse valeur ajoutée.
-D'intégrer ensemble des applications faites par plusieurs développeurs, et même les plus petites briques, et donc accroître l'interopérabilité. Deux grosses applications comme un forum et un blog doivent pouvoir cohabiter sans problèmes sur le même système. J'en ai vu pas mal des gens qui venaient demander comment utiliser son site et son forum phpBB ensemble, et on leur répondait à chaque fois qu'il fallait qu'ils trifouillent dans le code, et pas question d'utiliser le système d'utilisateurs de leur site, il fallait absolument qu'ils reprennent celui de phpbb car il était trop complexe pour être adapté.
-De ne plus avoir à modifier le code source pour installer un module.

On m'a demandé de comment je pensais que l'on pouvait améliorer les systèmes actuels, notamment de forum, j'ai répondu. Pour moi, c'est cela que devrait être l'avenir. Si pour vous, l'utilisateur peut très bien passer plusieurs jours à modifier le code pour que telle application et telle autre travaillent ensemble, c'est votre conception, mais je pense que si on peut permettre à l'utilisateur de le faire en 5 minutes et sans connaissances particulières, alors oui, ce serait un gros plus pour le web.
Et le truc ouvrir un skyblog, je ne suis pas de ceux qui pensent que la solution à ce problème sont des nouveaux systèmes propriétaires codés dans leur coin, car ce seront de nouveaux systèmes incompatibles entre eux, et c'est à cela que cette conception veut mettre fin, c'est à dire permettre à tout de monde de coder dans son coin, mais tout en permettant à l'utilisateur de tout utiliser ensemble.

-D'intégrer ensemble des applications faites par plusieurs développeurs, et même les plus petites briques, et donc accroître l'interopérabilité. Deux grosses applications comme un forum et un blog doivent pouvoir cohabiter sans problèmes sur le même système.

C'est ce point que je ne comprends pas du tout. Si je suis un gérant d'équipe commerciale, et que j'ai besoin d'avoir un intranet, je vais plutôt m'adresser à l'équipe informatique, et donc le pb de compétences ne se pose pas. En fait, j'aimerais que tu donnes un exemple de qui va utiliser ce noyau OSWEB;

Pour un forum + un blog, j'ai personnellement mis en place des systèmes qui s'intégraient bien avec une base LDAP (ah c'était un forum + un wiki, il est vrai).

D'une part, il n'y a pas que des entreprises qui ont le droit d'accéder à des logiciels web, les particuliers aussi, et on peut vouloir installer des applications sans avoir de connaissances en programmation, c'est le but de projets comme phpBB, ou encore beaucoup de CMS.
D'autres part, pour une entreprise aussi, pouvoir intégrer sans grands efforts deux applications ensemble, c'est autant de salaires de moins à payer. Si au lieu d'avoir besoin d'un gros service informatique, un simple webmaster peut installer les applications dont ton service commercial a besoin, c'est autant de gagné, surtout pour des PME ou TPE, non ? C'est comme si tu disais que l'on peut bien recoder Windows, ainsi que Office, SAP, ou encore VisualStudio, il y a des services informatique pour cela. Oui on peut, mais si on pouvait les avoir déjà fait, ce serait tout de même moins couteux quand même…

Oui enfin tout ce dont tu parles là, ça s'appelle des bridges, ou des plugins de CMS etc...

Et dans le cas où tu veux que "tout marche tout seul", il n'y a pas de mystère... Tu sembles imaginer un système où le noyau est tellement bien pensé qu'on pourra prendre n'importe quel appli et la faire travailler avec une autre de manière transparente. Désolé mais c'est tout simplement impossible, pour ce faire il n'y a pas 36 solutions, il n'y en a que 2 :
- soit on réécrit (partiellement ou totalement) l'application que l'on souhaite intégrer, pour qu'elle se comporte comme une brique facile à enficher dans le système (on appelera ça... hmmm... disons un "module", ou en anglais un "plugin" ?)
- soit on écrit une sorte de passerelle qui se charge de faire la communication entre l'application que l'on souhaite intégrer et le système (on appellera ça... hmmm... disons un "pont", ou en anglais un "bridge" ?).

Désolé, vraiment pas convaincu tout ceci existe déjà, en particulier dans les CMS existant (la notion de bridge y est particulièrement ancienne et populaire).

Regarde du côté de Joomla!, et dis-moi ce que ton système aurait de mieux, je pense qu'on comprendrait mieux où tu veux vraiment aller.

Non, l'idée n'est pas du tout dans le bridge, mais la première idée, à savoir que les applications doivent être codées pour le système, pour le noyau, je l'ai bien souligné. Il ne s'agit pas de créer un système magique pouvant faire tourner n'importe quelle application dessus, mais de faire un système conçu de telle manière à ce que l'implémentation d'une nouvelle application/module pour ce système réponde complètement à la problématique initiale de compatibilité, transparence, modularité, contrôle, …

j'ai vraiment du mal à comprendre le concept de noyau et son utilité.

pour moi, il faut une utilité, un usage pratique. ça se voit du coté des frameworks : on privilégie la simplicité, la modularité, tout ça, via un outil qui gère de plus en plus de choses.

avant on avait pear, un framework sous forme de bibliothèque de classes, maintenant on a symfony, un programme permettant de générer du code, s'appuyant sur des classes de base, mais faisant un boulot concret rapidement.

je ne vois pas ce qu'un noyau va m'apporter coté productivité et expérience de développement.

A+

Pascal

L'utilité est surtout au niveau de l'utilisateur plutôt qu'au niveau du développeur, arrêtez de penser à vous, pensez à ceux qui utilisent vos applications.

concretement, qu'est-ce que ça ferait coté utilisateur ?

A+

Pascal

C'est strictement identique, mais plus lisible, plus facile à gérer, et ça fait moins usine à gaz

Non ce n'est pas identique. La conception de l'interface va au delà d'une simple utilisation statique d'une classe. Si vous jetez un coup d'oeil dans la documentation vous verrez la différence.

Regarde du côté de Joomla!, et dis-moi ce que ton système aurait de mieux, je pense qu'on comprendrait mieux où tu veux vraiment aller.

Il y a de l'idée dans joomla, comme il y a de l'idée dans les framework, de même que dans les wrappers qui permettent de remplacer une classe par une autre. Mais dans chaque approche, il y a des inconvénients, à savoir que Joomla aura fait des choix préliminaires pour le projet, c'est à dire qu'il n'est pas livré avec le strict minimum, dans les framework, il y a l'avantage de la modularité, mais moins de transparence, et moins de compatibilité puisque le tout reste géré par l'équipe qui a codé l'application, et les wrappers permettent la transparence, mais il faudrait voir cela dans un système complet et abouti.

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

Légère digression

Vidéo de la conférence Framework Symfony disponible

Le 06 Mars 2007 a eu lieu un rendez-vous AFUP autour du thème Framework Symfony. Toute l’intervention a été filmée.

Je ressors..