Programmatique

110614 31 min
Un jour on m'a raconté qu'il fallait arrêter de faire des CMS, que dans l'avenir ça n'existera plus, il y aurait d'autres choses plus puissantes qui feront ça en n clin d'oeil.
J'ai plutôt le sentiment que si on pouvait revenir de 2030 à 2010 et qu'on voulait faire fortune, le voyageur se lancerait immédiatement dans l'élaboration d'un CMS, puisque c'est le temps qu'il lui faut.

En fait dans le futur rien ne pourra se faire sans CMS, lui-même sera à l'égal de l'informatique toute entière. On a inventé l'informatique, bien. Mais les logiciels informatiques, ça n'est pas rien
Par rapport à cela, le CMS est une plateforme de création de micro-logiciels, c'est à dire un système d'exploitation à l'échelle de tout internet. Au final il peut servir à tout ce qu'on peut faire avec un ordinateur, et c'est pourquoi le graphisme en a été dépouillé dès le début, c'est que ça doit ressembler à un OS, on pourra dire COS au lieu de CMS (c'est joli, les « opérations de contenu »).

Pour l'instant les CMS sont tous indépendants et pourront rester multiples, mais le fait d'avoir un langage qu'on connaisse est très important, quel que soit ce langage (ce peut être un langage d'objets qu'on manipule graphiquement, autant que la simple connaissance d'un fonctionnement), et avec lequel on peut produire des objets informatiques comme des blogs, des formulaires, du graphisme, des graphiques connectés à des bases de données, jusqu'à des réseaux sociaux, place immédiatement le CMS au centre de toutes ces activités humaines normales.

Il y a bien le langage de SPIP qui est devenu le langage des « wiki » ce qui l'a rendu reconnaissable et montré qu'il était possible et quel effet ça fait d'arriver sur un site en connaissant déjà son langage : on en devient immédiatement l'utilisateur.

Un CMS est d'office un objet public, et immédiatement le code source est assez modulaire pour être amélioré par celui qui le souhaite. Ça veut dire qu'il y a aussi dans le CMS une console, où on peut coder en dur ; autant l'utilisateur bêta que l'oméga (l'expert) doivent pouvoir prendre leurs marques rapidement.
Pour cela on a conçu le langage des connecteurs, qui dans sa forme la plus primitive est aussi simple à comprendre que le html.

A tout le moins on peut distinguer l'activité sur un CMS comme relevant autant de la programmation au sens où on doit créer des objets animés par la conscience du temps, que de l'informatique ou de la bureautique, qui consiste à utiliser des procédures connues.

Dans la programmation aussi on utilise des procédures connues mais elles sont plus aventureuses, techniques, on doit résoudre des problèmes de différents ordres : logiques ou topologiques, et faire preuve d'ingéniosité, ce qui confère aussitôt le caractère d'ingénieur au programmeur.

La complexité logicielle d'un programme comme un CMS est en évolution chronique, c'est à dire qu'elle est aspirée par le futur qui s'exprime en terme de nécessité créée par les derniers développements eux-mêmes. Sur la périphérie du système il y a tout un grouillement d'activité, et aller vers la périphérie d'un logiciel signifie qu'on grimpe sur des routines qui en incluent de plus en plus d'autres.

Arriver au stade où on n'applique plus que des gros objets qui savent eux-mêmes résoudre les différents conflits engendrés par des cas de figure découverts, on agit sur les automatismes, les scripts, des petites choses qui impliquent toute la mécanique qui les soutiennent.

La façon la plus visible qu'a ceci de s'exprimer c'est qu'on dispose d'une librairie de fonctionnalités générales qu'on situe comme étant le coeur (core) qui sont des fonctions tellement générales qu'on peut assez facilement les emboîter les unes aux autres, à condition de savoir ce qu'on fait.
En fait toute nouvelle fonction créée n'est que l'assemblage de ces briques élémentaires.

Cette discipline est l'endroit où on rencontre le plus de monde car cela se situe à la frontière du logiciel, c'est ce que j'ai appelé la programmatique, c'est quand l'utilisateur s'en mêle.

Et précisément toute la difficulté de concevoir un CMS consiste à proposer à l'utilisateur des objets qu'il peut assembler de toutes les manières possibles.
En toute logique tout objet n'est pas possible à assembler avec n'importe quel autre, c'est ce en quoi l'utilisateur prétend posséder un minimum de jugeote. Ne riez pas, ce n'est pas rien, c'est cette confiance qui permet de faire grandir de façon la plus importante le nombre de fonctionnalités disponibles, quand on sait que l'utilisateur va pouvoir s'en sortir.

Bien souvent il se produit que l'augmentation en complexité, par exemple le fait de proposer à l'utilisateur d'avoir des bases de données personnelles, de vrais tableurs avec un joli gestionnaire qui sait y appliquer plein de trucs utiles, a immédiatement engendré par la logique un notion d'ordre pratique (qui touche au palpable, même si toute cette activité reste mentale !) : il fallait que les bases utilisateur, déjà distinctes de bases similaires qui servent au système et ne sont accessibles qu'aux développeurs, soient capables d'échanger entre elles, et donc, qu'il y ait une base « public », qui est un peu comme le rejeton.

Car si il y a échanges, ce peut être entre adresses connues (c'est le super-admin qui s'en sert le plus), ou alors si c'est entre des gens, alors nécessairement il faut un lieu public pour faire connaissance de ce qu'il y a à donwloader (comme jolie petite base de données !).

Pour l'utilisateur cet espace public est désordonné comme l'espace des utilisateurs paraît désordonné à celui qui gère l'espace système, où là tout est super bien rangé.
L'espace public permet d'y ajouter ou injecter des données dans des bases existantes, autant que récupérer ou ajouter des entrées à une de ses bases personnelles.

Mais dès qu'on fait ça on suppose que les données injectées depuis l'extérieur ne sont pas abimées.
Au niveau programamtique, la fonction 'append' (qui permet d'enrichir une base à partir d'une autre) est l'expression en objets de ce qu'est la fonction php array_merge() destinée elle, au programmeur en dur.

@array_merge() combine deux tableaux en écrasant les clefs existantes par les nouvelles, ou en les ajoutant et les renumérotant si elles sont numériques, ce qui n'est pas terrible.
Append() s'est réservé une colonne pour la date de la dernière modification d'une entrée, et si une donnée arrivante est déjà existante, il ne l'écrase que si elle est plus récente.
On a besoin d'ajouter cette dimension de la date dans ce qui est pris en compte par l'algorithme pour obtenir de lui qu'il ne fasse pas n'importe quoi, comme écraser des valeurs qu'on vient juste de modifier. (append() est utilisé à tous les endroits du logiciel où s'exerce une mise à jour, bases systèmes, définitions d'importation, typos, classes css, etc...).
Si on se contentait d'écraser les données existantes sans raison ça partirait du principe qu'on connaît déjà le contenu du deuxième tableau entré en paramètre dans la fonction php classique array_merge(), ce qui est une grave violation du code de la généralité ! Les fonctions les plus basiques sont les plus utilisées parce qu'elles concernent des paramètres dont on est supposés ne rien connaître, à part que ce sont des chaînes de caractère ou des tableaux.

Quand on est dans le cadre de la programmatique et non plus de la programmation au sens dur, on a certes des fonctions plus « logiques » à utiliser, où il n'y a rien besoin de savoir, et qui remplissent leur rôle de façon attendue ou tout du moins, qui envoie à l'utilisateur une information à laquelle il n'avait pas pensé (et il se dit « ah bah oui ! »). Mais en même temps cette connaissance détaillée qu'on n'a pas besoin d'avoir puisque la fonction publique a été écrite pour être utilisée par un humain et non par un process, on la retrouve dans une somme de protocoles qu'il faut connaître, ou tout du moins un fonctionnement (c'est le côté bureautique).

Toute l'activité sur le CMS se déroule dans le contexte du CMS, et la façon dont il fonctionne est ce qu'il faut découvrir avant de pouvoir l'utiliser.
Le contexte du CMS est entretenu (dépoussiéré et lustré chaque jour) par la même sorte de désintérêt pour ce que veulent faire les utilisateurs, que les fonctions php de base sont désintéressées de l'usage réel qu'on veut en faire.

Tout ce qui compte c'est de pouvoir le faire, et tout le reste c'est trop hors de l'univers du geek.

-

Et donc soudain on se retrouve avec quatre choses à faire simultanément :
- créer un module c'est à dire réutiliser des routines existantes en créant des fonctions basiques qui seront partagées par celles-ci et par la nouvelles qu'on veut créer, connaître les fonctions basiques qui seront utilisées et mettre en place la commodité pour l'utilisateur en créant de nouvelles fonctions – c'est la raison pour laquelle le logiciel se doit d'adopter une topologie très ouverte, c'est qu'on veut avoir à expliquer le minimum de choses à l'utilisateur) ;
- permettre à l'utilisateur de créer ce même module qu'on est en train de créer (comment, lui, ferait ?) ;
- profiter de l'occasion pour éditer quelques cours de programmation grâce aux cas de figure très scolaires qui sont rencontrés ;
- garder la ligne de conduite du logiciel bien en tête, noter les nouveaux chemins évolutifs rencontrés (ah si on pouvait tout faire !), ne rien contrarier dans la mécanique. (non parce que rien ne peut se faire sans crainte de contrarier un autre processus, même s'il n'a rien a voir, il peut très bien être affecté par une sorte de résonance !)

Bien que la grandiosité de l'application créée soit grandissante – parfois en joignant deux fonctionnalités par une seule ligne de code, créant ainsi une fantastique émergence – on a besoin d'avoir à écrire de moins en moins de code pour cela.
L'opération faite en une seule ligne est le résultat d'une parfaite connaissance du terrain, et d'une idée qu'on aurait pu avoir plus tôt (balancer le flux rss directement dans le moulin à aspirer les articles), et c'est vers cet idéal que doit tendre le développement.

Pour que l'utilisateur puisse traiter avec des fonctions publiques il faut déjà au moins aussi que la façon dont est codé le système d'exploitation fasse appel aux mêmes préceptes organisationnels, qui sont hyper-strictes.

En fait on a régenté (obtenu par la force !) les modus operandi, en disant que chez nous en tous cas, le plus souvent on place l'information importante dans les clefs du tableau et non dans les valeurs, puisque ces informations sont toujours uniques (pas de doublon qui se fait écraser, à moins que ce ne soit volontaire pendant un tri), ou alors que les bases de données utilisateur allaient toutes toujours être utilisées avec les mêmes mécaniques.

Ainsi il a fallu sortir des routines classiques pour le traitement de ces microbases, comme « read », « save » « modif », sachant que tout ce qui utilisera ces fonctions sera au courant du format des données, et parfois des protocoles, sculptés par l'usage.

De nombreuses fonctions dans le logiciel nécessiteraient plus d'explication que leur nombre de lignes de code. Il arrive souvent qu'il faille d'abord aller se référer à la fonction pour voir comment elle marche, pour ensuite appliquer cela.

Dans la programmatique l'utilisateur devra suivre le même chemin que le programmeur, qui consiste à enquêter/appliquer (enquêter/appliquer et enquêter/appliquer), puis ensuite à chaque action commise en direction de son oeuvre, à coder/tester (coder tester et coder tester encore).

Si j'étais face à des étudiants je m'empresserais d'ajouter « Et ce sera comme ça toute votre vie ! »

Imaginez les gens de l'ancienne époque d'avant l'informatique, ils enquêtaient et testaient directement sans rien explorer du fonctionnement de leurs trouvailles. Et encore « enquêter » et « tester » ne sont que (le contraire d'un euphémisme !).
C'est comme ça que fonctionne encore la politique, la plus lente à évoluer des procédures humaines collectives, ils remarquent un truc, et passent directement à l'action immédiate et spontanée, sans même vraiment craindre de savoir si ce qu'ils font est utile ou a les effets attendus.

Dans cette mesure la programmation est, à l'opposé d'une démarche politique, une démarche scientifique, surtout que dans le monde de la logique dure, la manière la plus rapide d'avancer c'est de bien voir la réalité en face, en terme de limitations autant en terme de possibilités qui restent à explorer.

Les limitations sont données par le logiciel lui-même qui génère ses propres protocoles et autres petites habitudes. Parfois il arrive que certaines limitations ne fasse pas le poids contre l'intérêt de développer une nouvelle fonctionnalité, ce qui commande immédiatement une réforme des protocoles, au moins de ceux qui touchent à cette section du code global. D'autres fois il est arrivé qu'aucune routine ne pouvait gérer notre truc, et que cette routine n'allait jamais servir à personne, alors dans ce sas on compacte tout dans un plug-in externe. Mais cela arrive de moins en moins, le plus souvent, les plug-ins sont absorbés comme celui qui lit le rss, il s'est disséminé dans le programme et le plug-in est devenu obsolète.

Les limitations qu'on rencontre sont donc uniquement d'ordre topologique, la question pour ajouter une fonctionnalité à laquelle on n'avait pas pensé avant n'est pas si on peut l'implémenter, mais où, par quels chemins.

Dans l'idéal du futur de la programmation l'ensemble des routines seront elles-mêmes les production d'autres routines liées entre elles par des routines de liaison, ceci dans l'optique que le logiciel soit capable de se réformer lui-même, ou tout du moins, qu'on puisse jongler avec les protocoles et appliquer à l'ensemble du logiciel les transformations induites par cette évolution qui est incessante de toutes manières. (et on rigolera des gens qui se tapaient tout le boulot à la main à l'époque, alors que dans notre futur les protocoles sont instantanément auto-adaptatifs !).

-

Souvent l'ordre dans lequel on écrit une fonction va du plus simple au plus compliqué !
Évidemment puisque à l'école on a toujours dit « coder-tester, coder-tester ». Et si on fait cela on a besoin de tester avec des variables factices en attendant de brancher le nouveau venu dans le grand arbre de la vie. Et dans ce cas le coeur de la fonction ne cesse de se faire ensevelir par des méthodes, préparation des données, vérifications, éliminations d'exceptions légitimes ou fonctionnelles, etc...

Il est donc bon parfois de coder sans tester, en ayant tout en tête, en vérifiant quelques trucs en passant (un coup de plumeau quand on passe devant, c'est la règle !), et d'écrire toute la procédure telle qu'on se l'imagine avant même de pouvoir tester. Quand ça arrive, on doit ajouter des morceaux à différents endroits, qui envoient, qui reçoivent, qui filtrent, etc... Et on ne peut voir le résultat que lorsque tout est fini et implémenté, à par deux trois broutilles, dont une qui va prendre autant de temps que tout le reste. C'est comme ça qu'a pu sortir le principe de mise sous condition des modules affichés, la condition n'étant plus la page appelée, mais le type de page appelé, avec en prime le ciblage de page (et donc finalement des conditions qui dépendent de « la page appelée », sauf qu'on sait de quelle page il s'agit). Pour faire cela, il a fallu mettre tout le logiciel en chantier, déplacer des trucs, renommer des fonctions, intercaler des routines de contrôle, etc etc... Et c'est seulement à la fin qu'on peut tester, notamment, les systèmes imaginés pour faire les tris, qui sont compliqués à souhait.

Puis un jour, le stade suivant de l'évolution en complexité fait que cette jolie fonction a envie de sortir, de voir comment est le monde, et d'être utilisée par d'autres processus. Cette envie s'exprime de façon a-géographique, c'est une envie qui vient de l'extérieur. Il se passe simplement que la fonction a obtenu une bonne réputation et du coup il y en a d'autres qui se disent que si elles pouvaient profiter d'une de ses compétences qui sont très intéressantes, ça la boosterait, voire même ça ferait prendre une dimension nouvelle à tout l'ensemble du système, voire même, mais alors là c'est le succès à la Mickaël Jackson, ça pourrait motiver une refonte complète de l'ensemble de toutes les procédures !

Évidemment quand on utilise une fonction à petite échelle on n'a pas besoin d'envisager le cas de figure où les données proviendraient de processus complexes, où elles sont très strictement formatées, et qu'il faudrait pouvoir décoder et réencoder.
Non, on va confier cela à des sous-routines qui vont se mettre en orbite autour de celle qui est visée et tant qu'à faire, on va débarrasser la fonction qui veut servir à plusieurs processus différents des bribes de sous-routines qu'elle se trimballait pour des raison de commodité.

Alors à ce moment-là notre fonction que nous avons créée puis rembourrée se remet à perdre du poids, les procédures sont externalisées, et on liasse juste quelques indicateurs si c'est utile pour signaler des petites variantes.

Ces indicateurs pourraient dire « si tu vient d'ici, ça veut dire que tu es formaté comme cela, et donc je faire à la manière qui te convient », mais en fait on leur fait dire plutôt quelque chose d'impersonnel, du style 1/0, c'est un code entre nous, un coup tu mets des espaces, un coup des sauts de lignes, ça dépend du paramètre, pas de qui il vient.

Dès lors, même si ça aurait été plus simple que les indicateurs soient personnalisés, parce que dans ce cas ils s'appliquent de façon automatique, on fait passer en priorité des indicateurs relatifs, qu'ils faut connaître, et qui sont autant de sortes d'usages qu'on peut faire d'une fonction.

Il y a bien des automatismes, très nombreux, qui décident eux-mêmes par déduction les paramètres à utiliser avec telle ou telle fonction dans tel ou tel cas générique, ça existe, notamment pour décider où on peut ou pas afficher un module, savoir s'il y en a un autre, s'il peut y en avoir un autre, si son emplacement ne l'oblige pas à certaines restrictions ou si ses paramètres ne lui interidsent pas, en toute logique, d'interdire la mise en cache, etc... En fait les systèmes de contrôle sont là pour pallier au manque de souplesse engendré par la nécessité, c'est comme si cette souplesse s'était externalisée dans un lieu « mental » du programme.

Le fait de permettre à l'utilisateur de faire ceci à un niveau programmatique, alors que c'est la substance même de la prog normale, signale qu'on vient de faire un cercle complet sur le chemin hélicoïdal de l'évolution.
C'est la même chose mais à une autre échelle, et ce que ça implique, possède énormément plus de sens, mais aussi beaucoup moins de potentialité.

Ainsi le fait d'avoir, dans les grandes lignes, un fonctionnement et des habitudes, et d'avoir dans chaque cas de figure des exceptions et des procédures qui sont propres à la fonction qu'on désire utiliser, est le fruit de ce que la façon dont le programme est écrit est lui-même suffisamment élaboré pour pouvoir rendre visibles ces distinctions mécaniques.

-

Philum considéré en tant que plateforme de développement, conférant ainsi une nouvelle dimension au terme du CMS, lui donne un usage nouveau et inattendu qui consiste à pouvoir s'entraîner au rétro-engineering, se faire la main sur des choses simples, et au final permettre au public d'apprendre à coder.

Ce n'est plus une question de « open source » qui permet à l'utilisateur d'accéder à son droit d'ausculter le code du logiciel qu'il utilise, ça devient carrément une question de fonctionnement du logiciel que de permettre, en retour, qu'il serve pour l'éducation, car il a besoin des utilisateurs pour devenir meilleur.

Car en premier lieu il faut instruire l'utilisateur sur son fonctionnement, afin qu'il puisse vraiment profiter du plus grand potentiel possible de la plate-forme de développement.

Bien sûr depuis les premiers degrès de sa sophistication le logiciel permet toujours à l'utilisateur novice de débarquer, faire les choses banales en trois clics, et obtenir 90% de satisfaction avec le moindre effort.
Mais c'est devenu une nouvelle prérogative que de laisser de plus en plus de portes ouvertes à l'accès à des fonctions plus détaillées et plus sophistiquées, qui requièrent une connaissance, qui elle, a intérêt à être applicable hors du logiciel, au sens large, voire même au sens philosophique si on veut !

Donc non seulement le code est accessible, mais il est exposé, il est expliqué avec des notices d'utilisation qui s'accumulent à n'en plus finir, et enfin il est modifiable, et cela à différents niveaux qui sont très distincts :

1 - modifiable au niveau des paramètres, ça, c'est inévitable, aucun logiciel ne reçoit aucun paramètre, en raison du fait que résultat d'un logiciel dépend de l'humain qui appuie sur le bouton. C'est en somme une sorte de connexion entre l'électronique et le réel, il faut agit, donc ça se passe dans le champ de l'action, donc il y a des leviers et des boutons. Les gars ils peuvent revendiquer un code « propriétaire » il n'empêche qu'ils sont bien obligés de laisser une partie du code ouverte à l'injection de paramètres... et à partir de là, on peut faire ce qu'on veut !

2 - le logiciel est rendu plus malléable pour des raisons de commodité, car on veut permettre à l'utilisateur de faire des tâches qui ne sont pas explicitement attendues par le programme. Alors du coup on propose à l'utilisateur d'accéder à toute une classe d'objets qui sont injectés dans le système de sorte par exemple à lui permettre de changer la langue dans laquelle il est écrite, l'ordre et la position des objets sur la page, ou l'addition de règles qui doivent être prises en compte tout au long de la chaine de génération des données structurées et attendues par l'écran scintillant.

Pour cela on a distingué les restrictions (off/on), et la config (qui peut être globale, locale ou ponctuelle) et qui reçoit des valeurs règlementées (voire très règlementées).
La malléabilité dont je parle est celle qui consiste à pouvoir rajouter des fonctionnalités, des paramètres, des options de la config, autant que des modules, des connecteurs, des filtres de texte, des gestionnaires de types de boutons d'édition, bref tout ce qui fait la complexité future du logiciel, est régit selon des normes standardisées, qui sont apparues à force d'avoir besoin d'ajouter rapidement de nouvelles fonctionnalités. En l'occurrence, ça consiste à écrire une fonction et à signaler son existence au gestionnaire global qui prend forme de bases de données utilisateur, très simples à modifier.

- En enfin, à chaque fois qu'on a une nouvelle idée pour le logiciel en se disant que ce serait pas mal si il pouvait faire un truc qu'on a vu ailleurs, comme des onglets, on va devoir écrire le code en connaissance du code existant, en utilisant une de ses sept cent routines, et regardant bien ce que ça va donner, comment il va réagir, est-ce qu'il va falloir écrire plein de truc, etc...

L'aventure des onglets

C'est un truc banal, ça consiste à rendre visible une balise qu'on cible et donc rendre invisible celle qui était allumée.
Pour cela la méthode classique consiste à passer en revue toutes les balises et à les éteindre même si elles le sont déjà, puis allumer celle qui est demandée.
On a choisi de stocker en mémoire la précédente allumée, et donc de lui affecter un identifiant unique (car il peut y avoir plusieurs modules sur la page). On s'est embêté à faire cela parce qu'on a besoin que l'onglet cliqué reste allumé quand on navigue d'une page à l'autre, donc ça vaut le coup, et une fois cela créé puisque c'est nécessaire, pourquoi s'embêter avec l'ancienne formule qui consiste à tout passer en revue (même si c'est rapide) alors qu'on disposera par défaut d'une information utile ?

Quand on commence à écrire le module (stade primitif), on place cette information sur la page dans une balise « hidden » de façon à voir si ça tourne. Et quand on change d'onglet, l'ancien onglet est stocké sur la page. Plus tard on a besoin de le stocker dans la session, donc on couple le javascript avec un ajax juste pour appeler une page qui ne va rien faire d'autre qu'enregistrer une session. C'est un sacré ramdam pour très peu mais c'est marrant, puisque ça débloque plein de possibilités.

On avait déjà une version antérieure de ce type de présentation des modules, mais en ajax, c'est à dire qu'il allait se nourrir en temps réel à l'extérieur de la page lancée dans le navigateur d'une information qu'il avait pour mission d'importer. C'est vraiment très impressionnant comme activité car ça transforme la page qu'on consulte en une console dynamique alors que ce n'était qu'une page statique. L'usage qui en est fait est anodin, mais potentiellement ça peut devenir extraordinaire. Notamment on s'en sert pour recevoir les flux d'autres sites, ou du twitter en live.

C'est pour cela que la version html des onglets n'était pas développée, surtout qu'il faut charger toutes les pages dès le début, pour ensuite n'afficher que celles qu'on veut. Ce sont des données mortes, mais c'est pas grave parce qu'elles ne changent pas souvent, et par contre l'affichage est bien plus immédiat.

On avait aussi un problème avec les onglets en ajax, c'est que leur économie d'énergie oblige à ce qu'on ne sache pas si les onglets qu'on a demandé de voir apparaître seront nourri par une information, en somme, ils peuvent très bien être vides.

On avait résolu cela tout au début du logiciel quand il fallait que les catégories affichées ne soient pas vides, étant donné qu'on avait créé le « time_system » qui rend la publication périodique, hebdomadaire mensuelle etc...
et du coup certaines catégories pouvaient se retrouver vides.
Soit on testait (la présence ou l'absence d'articles) à chaque fois, mais sur plusieurs années ça aurait signifié cinquante heures de vie consacrés à cette seule opération, soit l'information en provenance d'autres routines plus profondes, et ayant acquit que la génération des données allait devoir se faire par passes successifs de plus en plus détaillés, il est devenu possible d'avoir avec les catégories (mises dans les clefs) le nombre d'objets qu'elles contiennent (dans la valeur du tableau), et donc de résoudre cet problème sans rien avoir à changer, seulement en s'informant bien.

Le modules d'onglets en ajax lui, reçoit des lignes de code qui sont fastidieuses, cela est dû au fait que c'est un module qui lance des modules, autant dire que ça n'était pas prévu, même si toute la mécanique des modules a été créée dans le but précisément de permettre d'avoir ce genre d'objet.
Les lignes de code disent quels onglets appellent quels modules avec quels paramètres, tout cela étant écrit dans la langue des connecteurs, ou du moins ce qu'elle devient quand on la pousse un peu, étant donnée qu'elle est faite pour être compréhensible par tout le monde, voire même pour remplacer le html.

Ce module d'onglets en ajax lui, va créer son oeuvre (où il n'y a plus qu'à cliquer), suite à quoi seulement on découvre si l'information est présente ou non, et si elle n'y est pas, on en ignore la raison. Au niveau graphique on signale au moins que le logiciel a correctement terminé son aller-retour, en faisant s'afficher avec un joli fondu-enchainé une jolie page bien vide.

Le module d'onglets html (appelé « tab_mods », comme ça on le confond bien avec tous les autres !) lui doit afficher le résultat au moment de la génération de la page, ce qui l'alourdit en temps et en taille, mais permet au moins de n'afficher que les onglets non vides.

On l'a vu, que ce soit pour les menus ou les menus des onglets, la même fonction qui consiste à ne pas afficher un menu vide repose sur des mécaniques qui sont impossibles à comparer entre elles ; ce ne sont pas des fonctions dévouées à cette tâche unique, mais le produit de fonctionnements.

-

L'aventure de la création de ce module « tab_mods » ne s'arrête pas là, elle est l'occasion parfaitement propice pour se demander comment l'utilisateur aurait pu avoir à oeuvrer pour obtenir la même chose.

Déjà au niveau de son fonctionnement, on a établi qu'elle recevait en paramètre un tableau, avec les onglets dans le clef et les données comme valeur. Elle tout ce qu'elle a à faire c'est de placer le contenu dans des balises. Elle fabrique les boutons, qui appelleront une fonction javascript, qui renvoie une variable se session, qui est interrogée par la fonction au moment de son lancement, ce qui détermine l'identifiant auquel se réfère le jeu d'onglets en cours.

C'est su-per-simple.

Le module en lui-même ne prend que cinq lignes de code, autant que pour le javascript dont on regrette de ne pas avoir pu utiliser d'autres existantes ou que celle-ci ne serve qu'à une seule chose.

Le bonheur de la programmation décorative, qui est le summum du purisme, consisterait à aller voir si on ne peut pas décomposer trois ou quatre fonctions d'une autre manière pour que, à nombre de lignes de code égal, on puisse utiliser ces ressources pour l'usage dont on a besoin... et plus généreusement encore, pour les usages de ce genre qui pourraient advenir dans le futur.

Ne pas y penser n'est pas humain, car on sait qu'on va avoir d'autres trucs comme ça à ajouter, alors que si on s'y applique pendant un moment, on aura seulement des choses à savoir au lieu de trucs à écrire. C'est donc éminement important, la programmation décorative, elle se fait dans un moment de bonté d'âme, quand on prend le temps de s'en occuper, alors portant qu'il y a d'autres choses qu'on venait de commencer et qu'on laisse en plan. Et la récompense est que plus on pousse le développement en terme de qualité et de densité, plus les interventions suivantes deviennent faciles, puisqu'elles déjà presque entièrement prises en charges. Jamais personne ne paiera un gars pour faire cela lol.

Dans une entreprise à mon avis ils n'ont pas le temps d'explorer ces chemins et c'est ce qui fait de la création d'un logiciel, d'une logique, une activité d'ordre scientifique, où la principale motivation est le fonctionnement, même si cela veut dire qu'il faut prendre des chemins détournés.

Car de cette manière on s'applique à ne pas laisser derrière soi un chantier de choses à faire qui s'accumulent, et qu'on peut très bien définitivement oublier si on a prit l'habitude d'ajouter des composants à tout va et de les faire s'appeler les uns après les autres. Il y en a quelques unes comme la partie ajax qui a engendré plusieurs versions d'une fonction d'appel avant d'en trouver une qui pourrait remplacer toutes les autres, si on voulait vraiment intercaler un constructeur à cet endroit-là.

Philum a dès le départ adopté l'idée du « built-in » c'est à dire que toutes les fonctionnalités doivent être accessibles par défaut dans le logiciel, aussi nombreuses et différentes qu'elles puissent être, ou dit autrement, qu'il n'y aurait pas de « plug-in » de tiers-éditeur, qu'il faut souvent acheter comme avec Joomla. Dès le début on veut que le système de commentaires d'articles soit poussé, puissant, rapide, intégré, et utilisant au maximum les ressources du noyau, de sorte à ne peser que quelques lignes de code, ce qui du coup ne justifie en rien d'avoir à l'entreposer dans un plug-in externe.

Ensuite il peut devenir possible de permettre à l'utilisateur de développer des fonctionnalités additionnelles à ces outils standards, mais au moins on veut qu'ils aient été pensés pour être les plus intelligents possibles, et le plus utile possible (il faut faire le ratio entre les deux !)

Mais de toutes manière l'utilisateur qui veut rajouter des fonctionnalités n'a pas à souffrir de la complexité et du nombre de routines existantes, pour lui on fabrique des emplacements avec des paramètres, et on fait en sorte que chemin faisant (dans sa pratique du logiciel) ça paraisse logique d'agir ainsi, voire même qu'il puisse déduire tout seul la façon dont les choses vont s'écrire.

A ce stade, il se passe comme tout à l'heure avec les bases publiques qui sont incomparables avec les bases utilisateur (privées et bien surveillées), qui eux-même n'ont rien de commun avec les bases système (super réglementées, avec des systèmes d'update internes, etc...) : le degrés d'intervention de l'utilisateur va du programmeur qui rend possible à l'utilisateur de faire ce qu'il fait, et même ensuite de l'utilisateur au visiteur, à qui il délivre des privilèges qui lui permettent d'interagir avec l'application, pas seulement en lisant-écrivant (write-read) mais aussi en posant des questions qui peuvent être inattendues (notamment avec la barre d'adresse qui est considéré par Philum comme une ligne de commande qui permet d'appeler n'importe quel module).

Et c'est toujours le même code de programmation qui est utilisé, à savoir le langage des connecteurs.

C'est très important d'avoir cette interface avec les fonctions publiques parce qu'il est hors de question de confier au public (à des gens qu'on ne connaît pas) les clefs de la mercédes pour qu'ils fassent tout ce qu'ils veulent avec.

Ce langage (des connecteurs) est si puissant qu'il est intimement connecté avec l'ensemble des sous-routines qui servent à produire la mise en forme tant sur le plan html que sur le plan de la pagination, au point qu'il est souvent opportun, au sein du logiciel, de préférer transporter des données déjà formatées en langage de connecteurs plutôt que formatés tels qu'ils apparaissent à la sortie, en html, et ce en raison notamment de l'économie de poids que ça représente.

Lui-même a trois couches de complexité, les connecteurs simple, un paramètre ou deux, et le nom de l'application appelée. Ensuite on peut avoir des connecteurs plus compliqués qui renvoient des lignes de commandes de modules. La seconde couche est le « codeline » qui permet utilise la même technologie (récursive) et qui s'applique exclusivement à la mise en forme, et enfin on a le « basic » qui sont juste des instructions mises à la suite, et par qui passent le paramètre arrivé depuis le connecteur. Ce langage basic est une interface avec l'utilisateur qui lui permet de créer des modules et des connecteurs, quoi que de façon très sommaire.

-

Il est vital de confier au public les moyens d'exercer son intelligence car avant tout un CMS est un lieu public, et ces gens qui en sont les utilisateurs, le logiciel ne sert qu'à leur rendre service.

Si on a compris ça on obtient aussitôt l'esprit dans lequel il faut être pour développer le logiciel en sophistication, et ça donne même une direction (dont découlent souvent de nouvelles fonctions de base qui sont très pertinentes), qui oblige à toujours penser à l'utilisateur, à ce qu'il peut avoir besoin, et notamment le besoin créé par les données sont présentées.

Parfois c'est la façon de présenter les données qui détermine ce à quoi on s'attend naturellement à ce moment-là. Le plus souvent l'idée vient après, une fois qu'on a un beau déroulé des statistiques, on aimerait pouvoir naviguer du visiteur à ce qu'il a consulté, puis de ce qu'il a consulté aux visiteurs qui ont vu cet article, et ainsi de suite, bref immédiatement, ce à quoi l'utilisateur s'attend le plus naturellement du monde, c'est un tour de magie.

En quelque sorte il faut être au devant de ce dont l'utilisateur a réellement besoin, c'est à dire avoir déjà préparé le terrain des endroits où il risque de s'aventurer. Et ce sont ces endroits qui deviennent des places, des villages des villes et des pays, dans la mesure où ils ont nécessité d'être le plus « développés ». (oui parce que il y en a un peu trop qui emploient ce mot sans vraiment connaître son poids !)

Et donc du coup la direction vers laquelle le logiciel se développe est à la fois celle qui est la plus pratique pour permettre les développements futurs et ceux, de plus en plus vastes, qu'on va déléguer à l'utilisateur.
Il ne faut pas croire qu'on peut tout déléguer à l'utilisateur, il y a toujours des parties, et en fait de plus en plus de parties, qui sont solides comme le rock, utilisées à un rythme soutenu, et que modifier ou altérer affecterait des applications distantes beaucoup trop nombreuses voire même impossibles à informer de ces réformes. Le noyau a tendance à devenir irréformable, et c'est pourquoi dès le départ il faut avoir eu la vision de ce qu'on veut obtenir, en l'occurrence que l'informatique soit un savoir du domaine de la culture au lieu d'un de ces fameux savoirs qui ont l'air d'appartenir à des gens qui ont l'air d'en être les seuls détenteurs... lol

Et pour autant ces fonctions du noyau du système, si on ne peut pas les proposer à être modifiées ou améliorées par l'utilisateur (à moins qu'il ait une idée géniale, comme ça peut arriver à n'importe quel moment !), n'ont pas à rester secrètes au contraires ce sont elles qui doivent être les plus connues. Elles peuvent être connues dans la pratique le jour où on la cherche parce qu'on a obtenu par déduction la certitude de son existence, et elles peuvent être connues pour ce qu'elles ont de scolaires, c'est à dire des réponses légitimes à apporter aux diverses manières possibles d'associer ensemble des fonctions php classiques. Elle peuvent servir dans n'importe quel autre projet, en cela ce sont des fonctions universelles, et c'est une intuition forte qui pousse à les faire connaître.

-

La rétro-ingénierie permettrait d'isoler des fonctionnalités du reste du logiciel, sachant que lui-même a été fabriqué en rétro-ingénierant des trucs open sources trouvés ici et là. A chaque fois on ne récupère que la substance pour comprendre le fonctionnement, et ensuite on applique cette fonction au contexte dont elle dispose, et en général elle s'y greffe parfaitement, sans avoir à recopier tout le baltringue de code proposé avec la source qui a servi d'inspiration.
Certaines sources utilisées ont été dépouillées de 75% de leur poids, parfois même 99,999% lol.

C'est pareil dans le sens inverse, si on veut isoler une fonction, par exemple le système de fabrication des CSS pour en faire une application autonome (ce serait pas mal) eh bien pour cela, ce serait difficile : soit l'étudiant veut juste trouver sa substance la plus élémentaire pour comprendre mieux l'ensemble, et donc il farfouille, démonte, efface ce qui sert à rien, etc..., soit on veut proposer une application qui ne sert qu'à cela. Dans ce cas, il faudra se retrouver avec presque l'intégralité des sources présentes dans le noyau, seules quelques unes devenant inutiles. C'est à dire que d'isoler cette fonctionnalité spécifique embarquerait avec près de la moitié du code de l'ensemble du logiciel, l'intégralité de sa structure et presque l'intégralité de son noyau ; et en même temps on en sacrifie énormément d'autres. Ce n'est donc pas une bonne opération, du moins tant que logiciel est aussi dense. (et il tend toujours à se densifier), à moins de couper la plupart des fonctions qui font l'intérêt de cette routine de fabrication.

Si on le fait ce ne peut être que pour informer l'utilisateur sur les fonctions existantes et la façon dont elles peuvent être jointes. A certains moments ça donnerait presque envie de dessiner des objets graphiques à assembler tant ils sont protocolisés.

Et dans l'idéal, il suffirait de cliquer sur ces objets pour lire leur « codeline » (code d'instruction qui sert d'interface en programmatique), et si l'utilisateur est vraiment en forme, il lui suffirait d'ouvrir un onglet auquel il est autorisé pour assister au spectacle triomphant de son module en train de traiter les paramètres qu'on lui a fourni et de renvoyer des données organisées avec brio.

Et y ajouter une petite note personnelle.

8119

Référencé par