Bienvenue

1007

Présentation du projet

Philum a été créé en 2004 pour répondre à un nombre croissant de besoins. Le Cms a vite muté en framework afin de permettre toutes les fantaisies de la croissance en complexité.

Cela a conduit à adopter une architecture novatrice, qui allie des choses parfois contradictoires :

  • un code rapide à développer mais aussi à comprendre (il faut choisir)
  • des processus génériques et déclinables
  • différentes couches logicielles, des plus stables et constantes ou plus sensibles à l'évolution
  • un code pensé objet, pas dans la forme mais dans le fond (avec des inclusions génériques).

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
  • d'une maintenance rendue très facile.

Présentation du framework

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

  • Celles du noyau, très simples et génériques
  • les tableurs qui préparent les données
  • et les constructeurs qui les assemblent.

A cela s'ajoute la couche des paramétrages qui appartiennent au CMS, avec une couche facile (les restrictions) et une couche poussée.

Les templates

Les templates sont pensés un peu différemment des autres CMS :

  • ils concernent uniquement des portions très personnalisables, laissant le maximum de dispositifs logiciels, qui évoluent avec les 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.

Architecture logicielle

Ce qui est difficile dans ce projet est de trouver la bonne échelle de ces fonctions et applications, car elles doivent à la fois pouvoir être incluses dans d'autres processus, et à la fois on doit pouvoir y puiser des fonctionnalités.

C'est pourquoi :

  • le framework est "orienté composants"
  • l'architecture logicielle, rendue possible par la souplesse (choix des composants et des méthodes) repose sur des protocoles très rigides

Langage programmatique

Pour jouer on a rendu possible d'écrire des modules ou des connecteurs sans avoir à entrer dans le code, avec les mêmes outils qui permettent d'écrire des templates.

  • le "codeline basic" (parce que ça écrit du code en une ligne) 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.

connecteurs, modules, plugins...

Les modules pré-existants 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.

Du plus simple au plus complexe :

  • les connecteurs, nombreux, peu paramétrables, qui sont au final des super balises html (logicielles)
  • les templates, dans lesquels on place les variables, rédigés en codeline (qui sont des connecteurs orientés 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.

Les connecteurs

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 fonctions qu'on pouvait appeler, de façon à les assembler pour générer des 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 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...

Utilisation des Connecteurs

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.

Les plugins

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

Protocole Ajax

Les requêtes ajax sont régies par un protocole à 9 variables (cible, application, source, traitement, var1, var2, var3, var4, multivars). Le socket multivars reçoit des données d'un formulaire ou aussi le résultat de AjaxMultithread, capable de faire voyager une énorme quantité de données, à 80Mo/s.
Tout le framework et le CMS fait usage de ce seul dispositif, aussi bien en interne qu'en production.

Usages

Finalement on peut très bien concevoir Philum comme environnement (caractérisé par sa grande légèreté) pour ne publier qu'un simple plugin, sur lequel le développeur passera tout son temps.
Il peut aussi bien servir de support pour écrire un mémoire que de base documentaire pour organiser les espèces animales entre elles (par exemple).
Au moins à l'intérieur d'un CMS l'éditeur de site possède des moyens puissants pour faire évoluer son projet.

Principales caractéristiques du Cms

Pour le visiteur

  • 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
Articles organisés sur plusieurs plans :

  • niveau de priorité (1 à 3)
  • catégorie
  • position dans un arbre d'articles
  • tags et classes de tags
  • référence à un autre article
  • dossier virtuel (sous-menus infini)
  • langue

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

Utilisateurs communs

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.

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

L'édition

L'édition se fait sur place, pour le texte (on travaille surtout sur le brut, sous philum, à part une prévisualisation sommaire), pour les méta ou pour les tags.

Les tags sont un chapitre important de philum, c'est la raison d'être du CMS, que de pouvoir classer l'information à un haut niveau de mises en relation.

L'architecture MySql est puissante et peut supporter de grandes quantités d'informations.

Les classes de tags :

  • les "tag' (systémiques)
  • les classes de tags additionnelles créées par l'admin
  • une classe publique (les public tags)

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

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, 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 (la base en dur de philum). Comme d'habitude ils sont déclinables et échangeables.

Les Mods sont édités dans la console, de façon très claire et concise.

Les Css

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, et à les présenter de différentes manières.
Le site marchera aussi bien sur un mobile ou une tablette.

A un premier niveau de curiosité on peut modifier son design et placer des modules dans un barre latérale.

Un utilisateur quotidien trouvera facilement des fonctionnalités même celles dont il n'en a pas souvent besoin, comme une admin de tags ou un espace disque. 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.

Le Desktop

A la naissance des popups ajax (qui étaient une innovation à l'époque), 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.

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
  • lancer des articles, de provenance interne ou externe
  • 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

Les Apps

Ces boutons du Desktop qui apparaissent sur le bureau sont des objet qu'on appelle des Apps. C'est le chapitre le plus sophistiqué de Philum.

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 contexte d'apparition des Apps :

  • 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

L'API

L'usage de philum sur 10 ans et la diffusion de 120 000 articles a graduellement conduit à centraliser les requêtes des plus centrales autour d'une API. Elle est responsable de la majorité des tris, par catégories, par tags, par auteur, par date.

Par défaut elle divise le résultat en pages ajax et en défilement continu. Si le paramètre 'time system' est actif, elle se charge d'afficher les tranches temporelles.

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.

Social

La socialisation des la production est bien plus complexe que d'afficher des boutons "publier sur facebook". Il s'agit graduellement d'inviter le visiteur à contribuer au site.

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

Enfin, il peut affecter des tags utilisateur aux articles et contribuer publiquement à la classification des données.

Conclusion

Le Framework, et le Cms qui en découle, sont de véritables outils qui permettent créativité et réactivité, le rêve de tous les geeks.

Rendez-vous sur :
- gitHub
- 1nfo.net
- philum_cms
Voir aussi
FractalFramework est un environnement de développent d'applications en POO issu de philum





dernière mise à jour: 1606