Présentation du projet
Philum est né en 2004 pour disposer de procédures génériques permanentes.
Le gestionnaire de contenu est devenu avec le temps un Framework (environnement de développement) afin de permettre toutes les fantaisies de la croissance en complexité.
Il a fallu adopter une architecture novatrice, qui allie des choses parfois contradictoires :
- un code rapide à développer mais aussi à comprendre
- des processus génériques déclinables
- différentes couches logicielles (lib, prog, plug), des plus stables et constantes aux plus sensibles aux effets du temps
- un code orienté composants.
Ces choix ont montré qu'ils étaient garants :
- d'un développement harmonieux : l'évolution est homogène
- d'une réduction substantielle de la redondance
- d'une vitesse d'exécution du code qui bat tous les records de vitesse
- d'une maintenance rendue très agréable.
En particulier sur cette idée fondatrice, qui consiste en une disposition fractale des composants du système (d'où le φ - une spirale est une fractale, et le nombre d'or en est l'unité), chaque dispositif peut engendrer n'importe quel autre dispositif.
Pour comprendre cela il faut exposer chacun d'eux.
- les fonctions du noyau, très simples et génériques
- les constructeurs qui préparent les données
- et les assembleurs renvoie le résultat vers la sortie.
A cela s'ajoute la couche des paramétrages qui appartiennent au CMS, dont une couche rapide d'accès (les restrictions) et une couche poussée.
Enfin une dernière couche de procédures Ajax permet de contrôler depuis l'interface n'importe laquelle de ces fonctions.
C'est pourquoi l'architecture logicielle est modulaire : la méthodologie de l'écriture des composants repose sur des protocoles très rigides, permettant de supplanter un processus par un autre, à n'importe quel niveau (contrôleur ou assembleur).
Le framework est "orienté composants" (ou neuronal) : c'est un choix assumé qui au final est responsable de la très grande vitesse d'exécution du code. Le système "neuronal" permet de rendre n'importe quel point joignable et compatible avec n'importe quel autre, en passant pas des "réseaux de neurones", ce qui revient strictement à de l'orienté objet, mais en s'épargnant sa lourdeur quand il s'agit de faire des choses simples. En réalité les objets sont, du coup, virtuels, et imbriqués en un nombre indéfini : il peut y avoir cinq objets imbriqués, dont on peut en appeler n'importe quelle partie ou sous-partie directement, elle et ses propres sous-parties.
En réalité les composants sont plus nombreux quand ils sont plus petits
- le "codeline basic" (qui exécute une action par ligne sans avoir à mettre les crochets des connecteurs) est une fonction satellite du "codeline" servant à rédiger les templates, qui est elle-même une fonction très allégée des Connecteurs.
- Il est possible d'y poser des résultats dans des variables ensuite traitées selon n'importe quel process.
connecteurs, modules, plugins...
Les modules pré-définis peuvent recevoir de nombreux paramètres, globaux, locaux et ponctuels. Leur affichage peut appartenir à différents contextes. Et ils peuvent faire appel à différents moteurs de rendu. Dans leur conception, ils permettent de choisir un type de constructeur et un type d'assembleur.
Du plus simple au plus complexe :
- Les connecteurs, nombreux, peu paramétrables, qui sont au final des super balises html capables de déclencher des actions logicielles.
- Les templates, dans lesquels on place les variables, rédigés en codeline (qui sont des connecteurs spécialisés en html).
- Les modules, qui utilisent des paramètres complexes de traitement, qui appellent des données et des moteurs de rendu.
- Les plugins, ont des tâches spécialisées, qui doivent être rédigées en php, en utilisant (ou pas) les ressources du framework.
Finalement, connecteur, module, et plugin ne sont que différents niveaux de complexité des fonctionnalités. La différence est le niveau de prise en charge qui va en décroissant :
- Le connecteur reçoit un ou quelques paramètres occasionnels. Sa fiabilité est maximale.
- Le module a des paramètres plus complexes : il permet de choisir la source, le contexte et le mode d'affichage des données ; on peut se tromper dans les paramétrages.
- Le plugin est éditable en tant que code source. On est totalement libre d'y faire ce qu'on veut. Il reçoit des caractères depuis le gestionnaire de plugins (propriétaire, en dev, classement partagé..). Il profite de l'ensemble des ressources du framework.
Même si ça paraît superflu à un bas niveau de complexité, ils ont des avantages indéniables :
- création de balises personnalisées
- possibilité d'appeler des micro-applicatifs (d'où le terme de "connecteurs")
- un parseur ultra-rapide organisé comme le décodeur html (succession-imbrication) : il lit d'abord les couches profondes
- et surtout, pas des moindres, ils permettent de rendre l'édition publique en facilitant la compréhension des balises et en contrôlant celles qu'on veut désactiver
Voici quelques exemples de connecteurs disponibles par défaut : (les connecteur se déclenchent avec un deux-points ':', sauf les formats de fichiers)
- une image.jpg active la balise, avec gestion des dimensions (en popup fullscreen si besoin)
- un lien url s'active automatiquement, en contrôlant la longueur du lien affiché
- .pdf affiche un player
- :video affiche une vidéo youtube, daily, vimeo depuis leur ID
- des galeries d'images (:photo, :slider, :sliderj),
- une :radio,
- une :petition,
- un livre d'articles (:book),
- un autre article local, sur place ou en popup (:popart)
- un article d'un autre serveur philum (:rss_art)
- un lecteur de bases de données utilisateurs lue avec un template (:msql_template),
- un menu ouvrable (:apps),
- un template (:codeline)
- etc etc...
Ce langage utilisateur sert à écrire le html autant que des modules, en ne les désignant que par leur nom de balise.
Il est relativement simple à lire :
[param|option:connector]
'hello' traité par le connecteur 'bold' :
[hello:b]
Appel d'un connecteur nommé 'my_plugin' (soit créé en PHP, soit créé avec les dispositifs internes), auquel on envoie $p=hello et $o=param optionnel :
[param|option:my_plugin]
Les connecteurs sont un premier niveau d'ouverture à l'utilisateur de programmation en ligne.
Utilisation des Connecteurs
- ils concernent uniquement des portions très personnalisables, laissant le maximum de dispositifs au logiciel, qui évolue avec les fréquentes mises à jour.
- le moteur de templates est très simple et rapide.
- ils utilisent des connecteurs spécifiques, qui servent à émuler le html.
- l'absence d'une variable désactive la balise dans laquelle elle s'affiche.
- une somme de restrictions (rstr) permet de désactiver de façon logicielle des fonctionnalités qu'on ne veut pas voir apparaître dans les templates.
L'écosystème des plugins a été particulièrement soigné :
- on peut les placer dans des sous-dossiers
- ils sont administrés et classés de façon logicielle
- rattachés à une doc automatique multilingue
On y accède par de nombreux points d'entrée :
- depuis d'autres plugins en tant que ressource,
- depuis une requête ajax (vers une popup),
- depuis un connecteur (dans un article),
- depuis un module (sur la page)
- en pleine page (/plugin)
- depuis une iframe (/plug)
La création d'un plugin nécessite quelques connaissances. L'appel d'un plugin (nommé 'name') est celui de la fonction plug_name(). Il n'y a que 2 variables ($p et $o) + un socket multivar ($res).
Par exemple un système de discussion en ligne, le "Chat", se rédige en 40 lignes de code. Pour commencer un plugin il faut se référer au plugin '_model', et le décliner.
//Pour appeler un plugin
plugin('model',$param,$option)
//Pour appeler une fonction :
plugin_func('model','model_build',$p,$o);
Mais finalement c'est avant tout un environnement logiciel qui peut être utilisé à de nombreux effets, tels que des sites-vitrines, des bases documentaires, un système de publication progressive d'ouvrages, une base de données sémantiques ou topologique (comme une taxonomie des animaux ou une généalogie), un "wiki", et surtout, enfin, un moyen de publier des applications personnalisées qui utilisent des sources de données très diverses.
Au moins le CMS possède des moyens puissants pour faire évoluer son projet.
Principales caractéristiques du Cms
- Html normalisé et ultra-rapide !
- Lecteur de flux rss et de pages web
- Accès aux données selon son propre choix de tri
- Moteur de recherche puissant, précis, et chronologique
- Restitution du site tel qu'il apparaissait à une époque antérieure
- Console Url facile à comprendre et à réutiliser
- Proposer des articles
Il y a 7 niveau de permissions :
- 1 = commentateur
- 2 = propose articles à la publication
- 3 = publie articles et modifie les meta
Pour le rédacteur de niveau 4
Publication d'articles et édition sur place
Aspiration d'article depuis le web (ou à la chaîne)
Partage de fichiers, d'articles et Chat entre serveurs
Édition du nuage de métas des articles
Pour le concepteur de niveau 5
- Développement Offline (sans toucher au noyau)
- Gestion des Mods (paramètres qui génèrent une page, on peut revenir aux anciens ou les partager)
- Gestion des modules et de leur fonctionnement conditionnel
- Création du design depuis l'interface (qui place les couleurs dans des variables, et permet de revenir / échanger des designs)
Pour un Admin de niveau 6
- Gestion de membres
- backups
- accès à une SGBD additionnelle de type "NoSql" où on peut voir et intervenir sur absolument tout ce que "raconte" le logiciel (les parties impossibles à définir des fonctions vitales du logiciel, dite "la partie molle").
Pour l'administrateur de niveau 7
pour lui chaque site est un hub sur sa base de données :
- capacité d'agir sur tous les blogs
- il peut attacher d'autres couches sur cette base (noeuds)
- ou tout refaire sur une nouvelle base,
- attacher un nom de domaine à un hub, une couche ou à une base
- (et ainsi donc) gérer des branches entre lesquelles des mises à jour peuvent s'opérer.
- (car) il peut développer en mode dev (sur les mêmes bases) ou en lab (sur d'autres bases) et mettre en prod ses apports (bref faire sa propre distribution).
Le logiciel est écrit de telle sorte que toute sa rédaction est externalisée ; il n'y a que des processus.
Il n'y a pas de documentation, c'est impossible à faire, mais il y a des bulles un peu partout.
Dans un logiciel en général, plus on confie de savoir à l'utilisateur et plus il a la liberté de se complexifier. C'est pourquoi c'est un outil assez spécialisé (orienté presse web).
Les tags sont un chapitre important de Philum, c'est la raison d'être initiale du CMS, que de pouvoir classer l'information à un haut niveau de mises en relations. Il existe autant de classes de tags qu'on le souhaite, et elles sont définies dans les paramètres du Hub. (Le Hub est la couche de l'utilisateur du Blog, sachant qu'il peut y en avoir autant qu'on veut).
Les classes de tags :
- les tags de la classe 'tag' (systémiques)
- les classes de tags additionnelles créées par l'admin
- une classe publique ("public tags") éditables par les visiteurs
Dans l'éditeur vous trouverez une grande quantité de dispositifs, dont la plupart vous semblera inutile jusqu'au jour où... Ainsi il est possible de backuper les articles et de revenir à d'anciennes versions, de nettoyer la mise en forme, d'intégrer des tableaux depuis des bases de données, des galeries d'images, ou des données issues du disque dur utilisateur, par exemple.
Ainsi il a été rendu possible de répliquer un article du web en un clic, depuis son Url. Évidemment si les définitions d'importation de site ne figurent pas parmi le millier de définitions existantes (et vite obsolètes), il reste facile de les éditer. Ensuite on peut importer les articles d'un site à la chaîne.
Un lecteur de flux rss permet aussi de consulter rapidement les publications des sites avant de les importer.
Le module principal est le "LOAD", qui affiche les articles d'après des paramètres globaux, affinables sur les modules.
Certains modules donnent juste l'heure et d'autres activent deux couches logicielles, la création de données, et leur assemblage.
Ok.
Les blocs de modules sont les DIV de la page. Il y a un bloc réservé et obligatoire, le bloc système, qui contient des infos sur l'architecture choisie, et les css utilisés (et dans quels contextes).
Ces ensembles de blocs de modules sont des "Mods" stockés dans des bases Msql (le gestionnaire NoSql de philum). Comme d'habitude ils sont déclinables et échangeables avec d'autres utilisateurs (via une API).
Les Mods sont édités dans la console, de façon très claire et concise.
Le premier bloc de modules qui s'appelle 'system' est un peu spécial, il n'affiche pas de résultats, il appelle des dispositifs logiciels qui eux, affichent des résultats. Et le tout premier module 'blocks' est l'index des blocs de modules.
Par exemple dans cette photo d'écran on peut voir que l'utilisateur utilise des modules "link" pour faire ses menus, au lieu d'autres modules qui permettraient d'en avoir qui soient automatiques.
On peut voir aussi le module "MenusJ", qui est le plus complexe des types de menus puisqu'il fait appel à des Apps, qui affichent de façon hiérarchique des résultats d'autres modules.
On voit aussi des 'codeline', il aurait pu y avoir de simples 'connectors' qui renvoient une mise en forme élaborée, mais 'codeline" est un véritable langage de programmation, permettant de renvoyer des résultats d'opérations faites en live, par exemple.
On possède 2 css, un local et un global. Le local est périssable tandis que le global est souvent mit à jour.
Le local peut être alimenté des nouveaux apports sur le local par défaut, obtenues d'une mise à jour.
L'idée principale est qu'on puisse faire évoluer ses css de façon continue car c'est ça la meilleure manière d'atteindre la perfection (du jour).
L'édition des styles se fait via un gestionnaire de CSS qui
facilite grandement cette tâche :
- séparation des couleurs et des définitions (usage de variables)
- édition en mode dev, puis passage en prod
- changements visibles en live
- création de déclinaisons
Usage minimal
Après une installation fraîche, le logiciel est disposé à publier des articles, de la manière la plus intuitive possible. Toute l'édition se fait sur place. Le site marchera aussi bien sur un mobile ou une tablette.
On pourra, en deux secondes, personnaliser les couleurs du site, et s'en tenir là pour l'instant.
A un premier niveau de curiosité on peut jouer avec les "restrictions", qui limitent les compétences du logiciel, afin de le simplifier. Celles qui sont activées par défaut concernent une utilisation en tant que Blog. Mais on peut très vite étendre les fonctionnalités du site par ces simples boutons de type OFF/ON qui activent et désactivent des compétences.
Un premier module très simplifié, nommé 'art_mod' permet d'associer des modules aux articles. Son fonctionnement est moins simple que les autres modules puisqu'il requiert de rédiger les scripts d'accès aux autres modules. Pour cela on peut s'entraîner dans une section "test" où on crée des modules et on copie leur script. Ce premier module est simple parce que les principales attentes sont déjà proposées par défaut, il suffit de l'activer, pour avoir par exemple un module qui dit "sur le même thème, lire aussi...".
Un utilisateur quotidien trouvera facilement des fonctionnalités même celles dont il n'en a pas souvent besoin, comme un gestionnaire de champs de tags ou un espace disque utilisateur. Son travail consistera à ordonner et organiser l'information.
Un développeur peut écrire des plugins qui peuvent être lancés dans l'article, en pleine page, dans une popup, ou comme iframe.
Au final Philum est un logiciel à complexité variable, et qui peut aller très loin pour satisfaire des usages très professionnels.
Les articles reçoivent pas moins de 15 méthodes de classement, de différentes natures logicielles :
- un propriétaire, qui associe l'article à un blog
- Un auteur, peut être inscrit au blog en cours
- une catégorie exclusive
- une catégorie transversale (les tags)
- un niveau de priorité, visible par les moteurs de recherche, de 1 à 4. Le niveau de priorité peut être nommé librement.
- une suite de classes utilisateurs de tags (des tags catégorisés)
- une relation de parentée avec un autre article (créant des dossiers d'articles)
- une langue, une association à d'autres articles d'autres langues
- une traduction locale (assumée par Yandex)
- une relation à d'autres articles (et de façon logicielle, une relations aux articles ayant prit celui-ci en référence)
- une classification dans un "répertoire virtuel", créé à la volée par les catégories choisies, et destinée à assemble n'importe quel article de n'importe quelle époque
- une marque en terme de "favoris" qui permet à l'utilisateur de créer son propre portfolio d'articles en signalant son "like"
- une marque en terme de vote, qui permet de faire monter au descendre l'article dans le ranking
- un classe de "tag-utilisateurs", qui permet au visiteur de classifier ses favoris et de partager cette classification avec le public
- un lien automatique rendu par les "recherches enregistrées" qui met en valeur les mots reconnus
Tous ces systèmes de classification permettent de relier le plus densément possible les articles ensemble, ce qui est vital dans le cadre d'une base documentaire.
Au final Philum reproduit sur un serveur ce que "le web" était sensé faire depuis le début : permettre de naviguer entre des thèmes et des logiques afin de s'acheminer vers l'information recherchée, qui est le plus souvent, il faut le dire, dispersée.
- les images
- les vidéos
- les fichiers audio
- les fichiers Pdf
- les liens web
- les twits
En particulier, les vidéos ont un gestionnaire puissant permettant de retrouver la source d'après le seul ID de la vidéo. Les vignettes des vidéos sont enregistrées et leur affichage est accéléré en plaçant une vignette qui ensuite fait appel à la vidéo.
Pour les twits, ils sont capturés via l'Api Twitter, qui permet de choisir une parmi plusieurs clefs d'Api. Les Twits sont enregistrés, et peuvent être administrés directement sur place (ajout de like, retweet, ou corrections).
Enfin les liens web peuvent être associés à un lecteur de m"tas qui propose d'afficher la description du contenu et une vignette, et ce pour tous les liens du contenu.
Une branche particulière de ce dispositif est réservé aux liens Wikipedia, qui bénéficient d'un lecteur incorporé sans avoir à aller sur le site. Le contenu est également enregistré.
A la naissance des popups ajax (qui étaient une innovation à l'époque, ce mot provenant d'une ancienne pratique), on voyait Philum devenir un Desktop : un bureau avec des icônes d'où on lance des activités qui apparaissent dans des fenêtres, sans avoir à charger de nouvelles pages. C'est très agréable et très vif !
Parmi les usages du Desktop, il y a :
- placer le site et la page d'édition des css côte à côte
- proposer au visiteur un espace de stockage et de partage de fichiers
- ouvrir plusieurs des articles simultanément, pour les étudier et prendre des notes
- ranger les articles dans des dossiers (les dossiers virtuels sont des chemins d'accès dont les nœud sont des tags)
- ranger les fichiers dans un répertoire virtuel partagé entre les utilisateurs
- etc...
C'est un dispositif d'appel d'application ou de fonctions, ou de liens, logés dans des répertoires virtuels et liés à des contextes. Il y a 4 contextes d'apparition de ce qu'on appelle les Apps (qui sont au final de simples paramètres d'activation de fonctionnalités du logiciel, et qui recouvrent toutes ses compétences) :
- menu/home : s'affiche comme menu déroulant ajax
- desk : s'affiche comme icône de bureau
- boot : est lancé au démarrage du Desktop
Les données utilisées par les Apps sont dans plusieurs tables Msql :
- les Apps Système
- les Apps par défaut
- les Apps utilisateur.
Les Apps fonctionnent en cascade, les nouvelles du même nom supplantent les anciennes (désactivation ou amélioration des Apps par défaut).
Une App peut lancer un élément appelé en ajax dans le menu en cours. Elle peut lancer un module, un connecteur ou un plugin.
les paramètres d'une App :
- bouton : texte affiché
- type : mod, plug, link, bub...
- process : nom du module, plugin, process...
- param
- option
- condition : desk, boot, home, user
- root : chemin d'accès
- icone
- private
Par défaut elle divise le résultat en pages Ajax avec un défilement continu. Si le paramètre 'time system' est actif, elle se charge d'afficher les tranches temporelles, et on peut retrouver l'état du site tel qu'il était des années avant.
Les requêtes sont publiées et peuvent être archivées de sorte à retrouver n'importe quel flux d'information à tout moment.
Enfin l'API distribue les données du site en Open Data dans des flux Json, de façon à permettre l'usage des données brutes par des applications tierces.
On a toujours souhaité que les autres sites distribuent leurs données brutes sans avoir à se coltiner leur mise en page, mais ils ne veulent pas s'y résoudre (et même, le rss tend à disparaître, ce qui est stupide). Pourtant on considère que tout site doit pouvoir se comporter en élément d'une application plus vaste.
En premier lieu, en output, on peut publier sur fb et twitter, notamment via une API twitter (qui nécessite un oAuth).
En input, l'utilisateur peut proposer des articles, les ajouter à ses favoris (en privé), les liker (en public), et procéder à des votes sur chaque article. Il peut recueillir ses données et en faire un 'book', accessible par une iframe qui peut être distribuée sur un site tiers.
Enfin, il peut affecter des tags utilisateur aux articles et contribuer publiquement à la classification des données.
Conclusion
Le Framework, et son Cms particulier, sont de véritables outils qui permettent créativité et réactivité. C'est un outil idéal pour les sites à haute fréquentation et qui nécessitent des mises à jour fréquentes.
Clients Philum
newsnet.fr : Une base documentaire de l'époque contemporaine.
oumo.fr : Un bureau d'études de documents.
FractalFramework
Une re-compilation des procédés développés pour Philum a engendré FractalFramework, un MVC Ajax destiné à permettre de créer des applications web, extrêmement incisif en terme de vitesse, débarrassé de toute la procédure de type CMS (hormis les connecteurs qui sont insurpassables), qui tourne sous php7.3 et MariaDB10.
Clients
tlex.fr : Un réseau social collaboratif d'échange de données.
socialnetwork.ovh : Un bureau web partagé.
Presse
numerama.com
[paypal:plug]
mis à jour le : 1812