1. Présentation
    1. Origine
    2. Pourquoi ce nom, "Philum" ?
    3. Architecture logicielle
    4. Utilisateurs
  2. Fonctionnalités
    1. Le système d'interface en Ajax
    2. Le framework Html
    3. Microsql
    4. Les articles
    5. L'Api des articles
    6. Les modules
    7. Les connecteurs
    8. Les templates
    9. Les plugins
    10. Langage programmatique
  3. Utilisation de Philum
    1. Usage minimal
    2. Usage poussé
    3. L'Admin
      1. Les Mods
      2. Les Css
      3. Le Desktop
      4. Les Apps
      5. Le Finder
    4. L'édition du contenu
      1. L'éditeur
      2. L'éditeur Wigwyg
      3. L'importation d'articles
      4. L'importation d'images
      5. Les métas
      6. Les médias
    5. L'API
    6. L'Api Vacuum
    7. Social
  4. Conclusion
    1. Clients Philum
  5. FractalFramework

Présentation

Philum est un CMS destiné à la publication soutenue.

Origine

Dès 2004 se sont fait sentir des besoins qui aujourd'hui encore ne sont pas remis en cause :

  • disposer d'un logiciel parfaitement indépendant des autres librairies afin d'offrir un logiciel libre qui échappe aux restrictions progressivement ajoutées aux faux logiciels libres
  • répondre à des usages très hétérogènes qui pourtant, sur un plan logiciel, utilisent à peu près les mêmes composants
  • être capable d'offrir technologies, des méthodes, des procédures et des protocoles qui soient novateurs, aussitôt que l'idée s'en fait sentir
  • axer le développement autour d'une prérogative qui a mit longtemps à être prise en compte, qu'est la vitesse d'exécution du code.

Pourquoi ce nom, "Philum" ?

Un phylum est un arbre taxonomique qui permet de visualiser les différentes voies évolutives ensemble. C'est ce que dessine un éclair dans le ciel et c'est aussi une bonne description du fait de réfléchir.

Le nombre Phi est associé aux fractions continues et ainsi aux fractales, et ce principe a été mis en œuvre dans la structure du logiciel en dessinant des dispositifs imbriqués dans lesquels les mêmes pseudo-actions se déroulent, à savoir, en gros, la question, les données et le rendu.

L'idée globale qui décrit à la fois la constitution du Html et celle du logiciel, et qui permet de décrire des organigrammes d'actions dans lesquels on peut se mouvoir. C'est une séquence appelée successive-récursive.

Architecture logicielle

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, des plus stables et génériques aux plus sensibles aux effets du temps
  • un code orienté composants.

Ces choix ont montré qu'ils étaient garants :

  • d'une croissance en complexité harmonieuse
  • 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.

Le but d'une conception fractale consiste à pouvoir créer des dispositifs complexes qui ne sont que des assemblages de différentes combinaisons de processus simples, et qui peuvent à leur tour être appelés depuis différents points. De cette manière n'importe quel processus peut profiter des aptitudes d'un autre processus sans pour autant avoir à l'appeler en entier. C'est bien plus sophistiqué au final que ce que permet de faire un code en POO, et dans ce cas le terme de "pattern design" s'applique aussi très bien, sauf que c'est plus modulaire. Cela s'est avéré déterminant pour laisser libre court à la créativité au moment de réutiliser complètement des dispositifs existants pour en faire tout autre chose.

Utilisateurs

Le système a été pensé initialement comme un générateur de blogs, qui eux-mêmes reposent sur des Nodes, qui sont des préfixes donnés aux tables Mysql, de façon à avoir plusieurs réseaux de blogs, par exemple joignables depuis différentes Url.

L'administrateur d'un blog possède des droits (niveau 6) octroyés par le superadmin, gestionnaire du serveur (niveau 7).
L'Admin peut à son tour octroyer des droits à un designer (niveau 4) et à un éditeur (niveau 4).
L'éditeur peut intervenir sur les articles des utilisateurs de niveau 3, qui ont le droit d'agir sur les métas des articles des autres utilisateurs de niveau 2.
Les utilisateurs de niveau 1 peuvent poster des commentaires, à moins que la config s'autorise le grand public à accéder à cette fonctionnalité.

Le superadmin décide du niveau d'engagement dess nouveaux utilisateurs, allant jusqu'à leur confier la création d'un blog, c'est à dire d'un envirnnement dédié entièrement vierge, et dont l'ensemble de la configuration est paramétrable, quoi que inspirée du blog d'origine.

Enfin, la pratique ayant fait muté le principe de blogs au profit d'un blog central auquel s'adjoignent des auteurs dédiés, un système de publication et de révision avant diffusion permet de contrôler et réguler les parutions des différents auteurs. Ils peuvent par exemple obtenir un design personnalisé sans pour autant quitter le blog d'origine.

Fonctionnalités

Le logiciel préfigure ce qui a été ensuite appelé MVC dans la mesure où certaines aptitudes ont suffisamment évolué pour devenir possibles à débrancher afin d'en brancher d'autres, ce qui a grandement facilité la maintenance évolutive et les deux refontes qui ont eu lieu. Tout le secret repose sur des protocoles qui sont nombreux et tout à la fois familiers.

Les fonctions sont classées par niveau de complexité :

  • les fonctions du noyau, très simples et génériques
  • les constructeurs qui préparent les données
  • 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 faite de modules et d'Apps, ce qui est le nom donné à des instructions qui peuvent contrôler l'ensemble des fonctionnalités.

Ordre de grandeur :

  • des paramètres serveur de niveau 7 logés dans dans fichiers externes
  • une configuration Admin de niveau 6, dits les paramètres système
  • un jeu interchangeable de configuration global du site, appelés les Mods, qui définissent l'aspect du site et le positionnement des objets
  • des Restrictions de type off/on qui permettent de désactiver des fonctionnalités natives du site de sorte à en optimiser la vitesse
  • des modules qui permettent de lancer l'ensemble des aptitudes du logiciel, dont une qui est la lecture d'un article
  • un dictionnaire de vocables et d'aides en lignes multilingue
  • l'Api de génération du flux, capable d'assembler les articles selon une grande quantité de sélecteurs
  • les Apps, qui peuvent appeler dans un menu, un module ou sur le Desktop, n'importe quel lien, module, ou commande d'Api

Au final tout ce qui apparaît sur la page est le fruit d'un choix et d'un paramétrage précis.

Le système d'interface en Ajax

Enfin une dernière couche de procédures Ajax permet de contrôler n'importe laquelle de ces fonctions.

Pour revenir aux débuts d'Ajax, peu croyaient en son avenir car c'était limitatif. Mais l'introduction du premier moteur multithread Ajax a permit de repenser complètement l'approche du système, désormais possible à concevoir comme un logiciel de bureau, dont on n'a pas à recharger toute la page à chaque action. C'est ainsi qu'est apparue la notion de Desktop, un mode de présentation plus proche d'un bureau windows.

Aucun besoin de React, Angular ou autre jouet de ce genre, puisque de façon native le logiciel est pensé à partir de ces aptitudes, en tant que système d'information auquel il suffit de brancher n'importe quelle nouvelle fonctionnalité.

L'interaction est extrêmement vivace et on a finit par éradiquer toute notion ancestrale de variable $_GET ou $_POST.

Le framework Html

De même, il nous apparaît très old school de vouloir encore faire figurer du Html ou des indications rédigées en dur au sein même du logiciel.

Le framework Html s'exprime sur deux niveaux, un premier qui est simplement une classe de fonctions qui génèrent les balises html, et ce sont elles qui sont appelées partout, ce qui a l'avantage de les centraliser et de les contrôler toutes ensemble.

Sur un deuxième niveau, qui à l'avenir s'étendra au niveau système (si un jour le Html est rendu obsolète par autre chose), une couche nommée Connecteurs permet de ralier le framework Html et bien plus encore, puisque ce concept permet de créer ses propres balises et d'y rattacher des fonctionnalités d'un niveau bien plus élevé que celui du framework Html.

//affiche une balise div avec des attributs
$d=bal('div',['classe'⇒'panel','id'⇒'obj123'],'hello');

//les balises et attributs courants on droit à des fonctions dédiées
$d=div(atc('panel').atd('obj123'),'hello');

Microsql

Dès le début la nécessité s'est faite sentir d'utiliser un gestionnaire de bases de données incisives affectée aux nombreux petits paramètres hétérogènes.
De cette manière il ne reste dans les bases de données Mysql (ou MariaDb) que les données brutes des contenus et des utilisateurs. Quand on fait une backup du site, ou un site miroir, il suffit de copier en dur sa clique de paramétrages particuliers.

Msql, selon son petit nom, est une SGBD de type NoSql développée pour Philum.
Elle permet, outre d'y loger les compétences, leurs capacités en termes de paramètres, et le verbiage du logiciel, de laisser à l'utilisateur l'usage de bases de données rapides qui peuvent être affichées ou utilisées dans les articles.

Le gestionnaire Msql permet de créer des backups de chaque table et de les transporter entre les serveurs.

Le temps d'accès aux données est maximal et imbattable, de l'ordre du millième de seconde. c'est devenu et resté un compagnon indissociable de Philum.

Les bases Msql ont de particulier d'avoir des classements prédéfinis. Ce sont des bases à taille humaine, car ce système devient insuffisant pour des données massives, où il vaut mieux faire appel à Mysql/MariaDb.

Tout tableau peut, depuis un article, devenir une table ou l'inverse, une table être affichée sous forme de tableau dans un article.

Une grande somme d'outils permettent d'administrer des bases de données utilisateur.

Les articles

Un concept de base du CMS était qu'un article est un objet, dans lequel on peut faire apparaître n'importe quel objet, y compris des articles par exemple.

Ainsi lorsqu'il est question d'un article, il s'agit en terme général d'un page web, étant donné qu'avec puis peut se déclencher toute une somme de fonctionnalités.

Les articles sont le souvent destinés à contenir des textes, qui peuvent être brefs aussi bien que très longs et structurés. En s'inspirant d'éditeurs de texte tels que Libre Office, de nombreuses compétences peuvent être attendues d'un éditeur de texte poussé, telles que les notes de bas de page, l'insertion d'images et de médias, et une structure des données.

L'Api des articles

Autour des articles plane un nuage de Metas qui sont différentes manières d'identifier le contenu, qui peut être mis en rapport avec les autres articles (voir section des métas).

La commande de l'Api permet d'assembler des articles d'une infinité de manières, et peut être sauvegardée comme telle, tout en restant réactive aux nouveaux articles, afin de créer des flux personnalisés.

Dans l'absolu l'Api, si elle es la colonne vertébrale du CMS, sert à distribuer des données au format Xml à n'importe quelle entité extérieure, qui voudrait les exploiter sur son propre logiciel.

Les modules

Les modules sont une grande somme de petits dispositifs prédéfinis qui renvoient des objets, initialement des panneaux de marge de page, des objets du type "articles liés", et puis par extension une grande somme de widgets.

Ce ne sont que de simples panneaux à paramétrer, avec des compétences limitées et dédiées à des tâches simples. Ils peuvent s'afficher en fonction d'un contexte, que sont la Home, la lecture d'une catégorie d'article ou d'un article, ou d'une catégorie précise et d'n article précis. Par exemple on peut attacher un design et une feuille css à un article ou à une commande d'Api, puisque même ces objets sont des modules.

De plus, les modules peuent à leur tour être sensibles à des paramètres, globaux, locaux et ponctuels, décidés en amont dans la config ou des restrictions. Enfin, les modules permettent de faire appel à différents systèmes de rendu, par exemple pour créer des icônes de bureau ou des panneaux qui servent de boutons géants.

Dans leur conception, ils permettent de choisir un type de constructeur et un type d'assembleur.

Les modules peuvent s'écrire sous forme d'une commande à 7 paramètres ordonnés :

cible_process_(capture)_(option)_var1_var2_var3_var4_v1|v2|v3|v4_injectjs

  • cible : id
  • process : application appelée
  • capture : (optionnel) un contenu sur la page
  • option : "x" ferme la popup, "2" empêche de clignoter, "3" affiche un loading, etc.
  • var1 à 4 : 4 variables possibles et c'est suffisant pour tout faire
  • multivar : captures sur la pages, par exemple des formulaires (Js détecte leur type)
  • injectjs : procédure visant à rétro-injecter du javascript dans la page en cours

Les connecteurs

Les connecteurs, nombreux, peu paramétrables, qui sont au final des super balises html capables de déclencher des actions logicielles.

Un connecteur peut recevoir zéro, un ou deux paramètres, nommés "p" et "o" (param et option), en suivant cette syntaxe :

[param§option:connector]

- 'hello' traité par le connecteur 'bold' :

[hello:b]

Les connecteurs font bien plus que ce que font de simples balises.
L'idée géniale du logiciel était de faire que les balises soient autant de moyens d'appeler de veritables micro-applications.

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 commence par les couches profondes et applique le rendu aux couches de surface
  • 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, comme le fait le BB-code de Wikipedia, mais de manière bien plus éléguante.

Voici quelques exemples de connecteurs disponibles par défaut :

  • 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...

- Appel d'un connecteur nommé 'my_plugin' (créé en PHP par l'utilisateur) :

[param§option:my_plugin]

Les connecteurs sont un premier niveau d'ouverture à l'utilisateur de programmation en ligne.

Liste complète des connecteurs

Les templates

Les templates sont des petites portions de code qui assument la mise en forme de données, et qui sont rédigés sous forme de connecteurs un peu spécialisés, qu'on appelle le Codeline.

Le Codeline permet de stocker et renvoyer des données au cours de la lecture du template, de façon à rendre la présentation de balises imbriquées plus claire.

Les templates par défaut peuvent être supplantés par des versions modifiées localement ou globalement, c'est à dire par un utilisateur unique ou par une somme d'utilisateurs partageant des ressources publiques.

Les plugins

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

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.

C'est à cet endroit que peuvent être ajoutées des compétences non initialement prévues, et adaptées à chaque situation. L'usage des librairies du framework permet d'accélérer de façon providentielle le développement, pour cela il suffit de s'inspirer des fonctionnalités connues et observées, et de voir comment elles sont déclenchées. Le logiciel dans son ensemble exploite toutes ses possibilités, donc il y a toujours un modèle déclinable pour de nouvelles applications.

Par définition les plugins sont des fonctionnalités satellites au logiciel. En pratique certains sont indispensable quoi que relégués, et la plupart sont des outils pratiques.

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);

Langage programmatique

Pour rendre possible le développement de modules par l'utilisateur sans qu'il ne vienne modifier le code source (qui est remit à jour régulièrement), on a proposé un langage de programmatique original sur la base du langage des connecteurs, qui permettent également d'écrire des templates.

  • 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.
Ici un connecteur personnalisé (et beaucoup de lignes en commentaire). "?" définit, "!" affecte, "=" utilise, et "_" est une var. Oldschool :)

Utilisation de Philum

Outre l'usage en tant que blog, Philum est écrit plus généralement pour la presse web, ce qui est plus élaboré.

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.

Philum est un outil complexe et poussé.
Pour concevoir un site créatif, il faut une plateforme dont toutes les routines soient déclinables et améliorables. Pour cela, il faut à son tour que le code suive des règles faciles à comprendre et applicables intuitivement ensuite.

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.

Usage poussé

Ensuite on peut créer des accès personnalisés à des pages ou à des modules (ou à des plugin) en utilisant les contextes. C'est à dire que par défaut les pages s'affichent dans un des trois contextes de base que sont la Home, "cat" pour le déroulé des articles d'une catégorie, et "art" pour la lecture d'un article. Chaque module peut être associé à un de ces contextes.
Pour créer des contextes personnalisés il suffit d'affecter son nom arbitraire (genre "choses") au module. Ensuite cette page sera joignable depuis un autre module situé dans tous les contextes ("all"), qui affichera un menu (un des nombreuses sortes de menus).

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.

L'Admin

Les Mods

Le composant principal sont les modules. Ce sont des fonctionnalités du framework.

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, les 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 d'architecture, comme les css utilisés (et dans quels contextes).

Ces ensembles de blocs de modules sont appelés des "Mods", stockés dans des bases Msql (le gestionnaire NoSql de philum). Ils sont donc déclinables et interchangeables. On peut en importer d'autre sites Philum.

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, que sont (ici) le menu, la navigation, etc.).

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, afin de les personnaliser.

On peut voir aussi le module "MenusJ", qui assez complexe puisqu'il fait utilise des commandes d'appel d'autres modules et en fait un menu.

On voit aussi des 'codeline', ce ont des commandes assez poussées qui permettent d'appeler des fonctions du noyau, ici pour renvoyer des résultats dynamiques ; Il aurait pu y avoir de simples 'connectors' qui renvoient un contenu mit en forme.

Les Css

On possède 2 css, un local et un global. Le local est périssable tandis que le global est commun à tous les sites, et contient les définitions utiles au système. Dans la pratique le css par défaut évolue très régulièrement aussi, il n'est pas mauvais de s'en réinspirer de temps en temps.

L'idée principale est qu'on puisse faire évoluer ses css de façon quotidienne car c'est ça la meilleure manière d'atteindre la perfection (du jour). Cet éditeur de Css permet un gain de temps prodigieux et offre une visibilté globale sur l'ensemble des styles.

Vous aurez remarqué les 3 X 3 colonnes pour les couleurs, ce sont, dans chacune d'elles, les définitions du texte, du lien et du :hover, et chaque colonne concerne la couleur du texte, du fond et du contour. C'est un myen sympa de raccourcir une grande somme de définitions. Il ne reste plus dans la colonne "free" que les styles un peu plus spécifiques.

L'éditeur de styles permet :

  • une séparation des couleurs et des définitions (usage de variables)
  • une édition en mode dev, avant le passage en prod
  • de voir les changements en live
  • de créer des déclinaisons

Le Desktop

A la naissance des popups Ajax, le terme de "popup" relevait d'une ancienne pratique de mini-fenêtres sans boutons. Cette innovation on permit à Philum de 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 :

  • Editer un contenu ou faire des commentaires au fur et à mesure de la lecture
  • Ouvrir d'autres articles sans quitter celui en cours pour faire des comparaisons
  • Transformer (en une option) tout son site en un bureau de type windows
  • Placer le site et la page d'édition des css côte à côte
  • Ranger les articles dans des dossiers
  • etc...

Les Apps

Les icônes du Desktop sont des objets qu'on appelle des Apps. C'est le chapitre le plus sophistiqué de Philum.

C'est (tout simplement) un dispositif d'appel pour n'importe quel processus du logiciel. Parmi ceux-là il y a celui qui permet de naviguer dans une hiérarchie d'Apps afin d'en faire un menu déroulant, des dossiers imbriqués, ou même si on pousse le concept "une histoire dont vous êtes le héros".

L'App la plus simple est juste un bouton qui renvoie un lien. La même commande peut appeler des modules, des plugins, ou n'importe quelle requête Ajax.

Il y a 4 contextes d'apparition des Apps :

  • home : s'affiche dans le menu Home de la barre d'Admin
  • menu : s'affiche dans le menu de navigation (qui est public) de la barre d'Admin
  • desk : s'affiche comme icône de bureau
  • boot : est lancé au lancement d'une page dans une popup

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).

Les paramètres d'une App :

  • bouton : texte affiché
  • type : mod, plug, link, bub, ajxlnk...
  • process : nom du module, plugin, process...
  • param
  • option
  • condition : desk, boot, home, user
  • root : chemin d'accès
  • icone
  • private : niveau de permission requis pour y accéder (0 à 7)
Un peu austère et difficile d'accès le menu des Apps permet entre autres de produire des menus hiérarchiques en Ajax. Il suffit de spécifier le chemin dans root, et une condition d'activation telle que 'menus'.

Le Finder

Le Finder est un navigateur de fichiers qui permet d'administrer des dossiers et de les partager entre utilisateurs. Les fichiers sont disponibles lors de l'édition afin de les inclure dans les contenus.

Le Finder détecte les extensions et y adjoint un lecteur adapté, que ce soient des images, des musiques, des Pdf ou des vidéos.

D'office quand on ulpoad un média dans un article, il va se loger dans le répertoire utilisateur (au lieu du répertoire commun des images) et dans un sous-dossier typé (vidéo, Pdf, etc.) afin d'y être administré.

Finder, le gestionnaire de fichiers

L'édition du contenu

Le contenu est intégralement rédigé en connecteurs, à la place du Html. Le gain de place dans les bases de données est conséquent (près de 30%). Ce dispositif est garant de l'uniformité des contenu, quelle que soit sa source.

L'éditeur

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.

L'éditeur Wigwyg

Les articles sont également éditables sur place, directement dans le corps du contenu.
Dans ce cas les connecteur non reconnaissables par l'importateur Htlm figurent en dur.

L'importation d'articles

Faire rebondir un article de presse lui donne du poids, c'est une activité qui n'échappe pas aux moteurs de recherche.

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. On peut même batcher l'importation d'articles depuis des flux rss.

Un lecteur de flux rss permet aussi de consulter rapidement les publications des sites avant de les importer.

L'importation d'images

Il y a trois modes pour importer des images,

  • soit on les upload depuis son disque dur, mais ceci dans la réalité, n'arrive presque jamais
  • soit on spécifie simplement l'url d'une image sur le web, et elle est automatiquement enregistrée, renommée correctement, et mise au registre du catalogue d'images de l'article
  • soit, le plus sypa de tout, il suffit de la glisser-déposer sur l'article en cours d'édition Wyswyg. Ce n'est même pas un script javascript qui prend du temps à se charger, c'est juste instantané.

Les métas

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

Les "Métas" donnent un contexte à un article. Un article est considéré à la base comme l'élément principal d'une page, bien qu'il puisse en pratique contenir en lui-même n'importe quel objet (module, plugin, connecteur) ou autre article.

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 médias

Grâce aux connecteurs, la gestion des médias est facilitée. Le logiciel permet de produire des résultats de contenu en fonction des médias qui s'y trouvent, tels que :

  • les images
  • les vidéos
  • les fichiers audio
  • les fichiers Pdf
  • les liens web
  • les Twits
  • les Wiki

En particulier, les vidéos ont un gestionnaire très sympa qui permet de n'utiliser que l'ID d'une vidéo, qu'elle soit de Youtube, Vimeo ou autre. Les vignettes des vidéos sont enregistrées et leur affichage est accéléré en rendant la vidéo accessible seulement après avoir cliqué sur l'image.

Les fichiers Audio peut se collectionner en un lecteur Mp3.

Les fichiers Pdf sont accessible sur place dans une popup.

Si on active cette option, tous les liens web reçoivent un icône permettant de visiter les en-têtes du site visé, donnant un titre, une image et une description du contenu. Ensuite si on veut on peut ovrir ce contenu entier sur place, sans avoir à visiter le site, et sans quitter la lecture en cours.

Les twits qui peuvent figurer dans des articles sont capturés via l'Api Twitter, qui permet d'avoir plusieurs clefs d'Api. Les Twits peuvent être administrés directement sur place (like, retweet).

Les liens vers Wikipedia qui bénéficient d'un lecteur incorporé sans avoir à aller sur le site. Le contenu est également enregistré en cache.

L'API

L'usage de philum sur 16 ans et la diffusion de 150 000 articles a graduellement conduit à centraliser les requêtes autour d'une API. Elle est responsable de la presque totalité des tris, par catégories, par tags, par auteur, par date, et a supplanté un grand ensemble de procédures hétérogènes.

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, de façon à naviguer dans le temps.

Les requêtes sont visibles et peuvent être archivées de sorte à retrouver n'importe quel flux d'information à tout moment.

Enfin l'API distribue les données 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 (ce que le rss fait parfois même s'il n'est hélas pas généralisé). Pourtant on considère que tout site doit pouvoir se comporter en élément d'une application plus vaste.

Pour appeler les données d'un article Philum :

/api/id:319,json:1

Pas moins de 43 paramètres attendus par l'Api, capable de gérer les langues, les formats, les tags utilisateur, les recherches, ou même encore de créer un fichier html à la volée.

L'Api Vacuum

Pendant quelques temps Philum s'appuyait sur Mercury, une Api qui renvoie les données brutes des sites, de façon adjointe avec ses propres procédures dédiées à cette tâche. Mais depuis sa disparition, a été instauré l'Api Vacuum, qui reproduit ce résultat, et renvoie des données les contenus formatés, normalisés, et en mode connecteurs, en Json au client.

Pour appeler les données de n'importe quel site (ici en utilisant les connecteurs à la place du html) :

/vacuum/philum.fr/319&mode=conn

Social

Les services au visiteur sont plus élaborés que de simples boutons "publier sur facebook". Il s'agit graduellement d'inviter le visiteur à contribuer au site, et de lui permettre de confectionner des collections.

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 à fort traffic, qui nécessitent des mises à jour fréquentes et une maintenance évolutive soutenue. Mais il peut aussi servir des tâches simples, comme celles de confectionner des galeries photos ou d'écrire un livre en ligne.

Le plus grand point fort de Philum est sa vitesse d'exécution, grâce à son principe de "densité du code", puisque les pages s'affichent, sous PHP7.3 avec MariaDb, sur un serveur Vps à 10 euros par mois, et une base de données de 1.5Go, en 0.007 secondes (mais oui ! A peine plus qu'une simple requête Mysql !).

Son deuxième point fort est sa longévité, puisque c'est le plus vieux Cms du marché qui existe encore sans avoir à être refondu, et qui aujourd'hui encore recèle d'innovations pour l'avenir.

Le dernier point fort est l'harmonie de sa croissance en complexité, puisqu'il a supporté presque deux décennies de mises à jour, prouvant ainsi l'efficacité de son architecture de type fractale.

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