Bienvenue

£§q M : N 100709

Présentation du projet

L'idée est que si on fait un travail il faut qu'il serve le plus longtemps possible. L'informatique permet d'ajouter l'intelligence des uns et des autres, au fil des années.
C'est donc naturel que les logiciels soient rédigés non pas seulement pour fonctionner mais aussi pour être lus, compris, entretenus et développés. Et ces cités restent belles tant que leurs idées restent belles !

Présentation du framework

Le développement d'un site à haute fréquentation et avec une publication constante a conduit à construire des outils de traitement des données aussi variés que complexes.

Le logiciel et tous ses composants sont écris selon la forme :

définition => constructeur => assemblage

L'avantage de l'orienté composant est de pouvoir assembler n'importe quel processus utilisant n'importe quelle source de données.

Ainsi les fonctions sont classées entre celles du noyau (très simples et n'en appelant aucune autre), les processus (qui utilisent des fonctions publiques et des privées), et les dispositifs d'assemblage des données.

Au chapitre de l'assemblage il faut surtout noter le fait que les processus soient tous conforme à des protocoles connus par les assembleurs. Pour cela on a nommé différents types de tableaux multidimensionnels (aux doux noms de v, k, kv, kkv etc...)

Ainsi les templates sont traités par des fonctions satellites de celles qui ont généré les variables qui vont y être injectées [c'était obligé sinon ça tournait en boucle].
En fait, plus simplement, on a un énorme dispositif nommé "les connecteurs" qui remplace le html. Le contenu des données est contrôlé balise par balise (et le superflu est supprimé), de façon à produire des pages 30% plus légères qu'en html.
Surtout ces connecteurs font bien plus que ce que font de simples balises.

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

Ce qui est difficile dans ce projet est de trouver la bonne échelle de ces fonctions et applications, car au final ça commence très bas, et ce qui apparaît à l'utilisateur est déjà de l'ordre de la troisième couche système du logiciel (puisque les assemblages de fonctions constitue autant de composants pour d'autres assemblages).

C'est pour cette raison que le framework est "orienté composant", ce qui parfois fait grimacer... En fait si on veut les assembler à la chaîne (de façon fractale), cela suppose une très grande rigidité dans la façon dont elles sont organisées, régies et rédigées.

L'outil mis à disposition pour créer des fonctions (utilisées comme modules) en est à une phase extrêmement primitive de son évolution, et ça s'appelle le "codeline basic" (parce que ça écrit du code en une ligne). C'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.
Bon pour l'instant ça sert juste pour des petits automatismes,comme par exemple ceux qui donnent des stats sur le logiciel, en page de download).

Sinon à part ça il reste à utiliser un parmi une centaine de modules et ses nombreux paramètres globaux, locaux et ponctuels.

En résumé on a :

  • des modules qui utilisent des paramètres complexes (ce sont des traitement, qui réclament des données et des modes d'assemblage)
  • des connecteurs, nombreux, peu paramétrables, possible à rédiger en clbasic
  • des templates, dans lesquels on place les variables, rédigés en codeline (qui sont des connecteurs orientés html)
  • des plugins, qui ont des tâches spécialisées, qui doivent être rédigées en php, en utilisant (ou pas) les ressources du framework.

Les connecteurs

Les connecteurs sont des commandes pour des activités, qui peuvent être complexes. C'est finalement l'accès complet à un logiciel (logé dans un plugin). Ils sont parfois plus complexes que les modules, peuvent servir de modules ou utiliser leurs ressources.

En fait les plugins peuvent être appelés en tant que module (hors de l'article) ou connecteur (dans l'article).

Voici quelques exemples de connecteurs disponibles par défaut :

  • des liens opérationnels (youtube renvoie une popup, pdf un player... et une image : pas besoin de la rédiger
  • 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 d'après un template (:msql_template),
  • un menu ouvrable (:apps),
  • un template (:codeline)
  • etc etc...

Les plugins

L'écosystème des plugins a été particulièrement soigné, parce que les plugins on peut en avoir besoin à de très nombreuses étapes (ou échelles) du logiciel.

Ce qui les caractérise est qu'ils ne sont pas vitaux pour le logiciel, même s'ils peuvent être requis par des options qui ne sont pas celles par défaut (déjà à ce stade).

  • Ils doivent être rendus disponibles pour d'autres plugins en tant que ressource,
  • depuis une requête ajax (dans une popup ou pas),
  • comme bouton ouvrant le plugin dans une popup
  • au sein d'un article en rédigeant le connecteur,
  • en tant que bouton connexe à un article (comme les liens sociaux)
  • comme module placé sur la page
  • en pleine page /plugin/
  • ou appelée depuis une iframe /plug/

Les plugins sont très simples à rédiger, à part qu'il faut s'accommoder de ses contraintes (deux variables libres et un socket multidonnées 1), mais en profitant de dispositifs puissants faciles à pomper sur d'autres plugins.
Une classe objet 'Msql' permet la gestion de bases de données utilisateur.
Au final un plugin comme le Chat (en ajax) s'écrit en 40 lignes.

1 les requêtes ajax régies par un protocole à 9 variables (cible, application, source, traitement, var 1, var 2, var 3, var 4, 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.

Usages

Finalement on peut très bien concevoir la présence de 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).

C'est pourquoi le CMS est un Framework, parce que les fonctions système sont élémentaires, et que le principal se trouve dans la facilité à ajouter des fonctions et à les activer, dans un environnement où on peut se loguer, auquel on peut se référer, et où tout est balisé et rôdé.

Le progrès à faire sera de rendre cette rédaction de logiciels de plus en plus intuitive, tout en gardant l'esprit assez clair pour savoir ce que cela signifie...

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 faciles à comprendre et à réutiliser
  • Proposer des articles

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 (et même à la chaîne)
Partage de fichiers, d'articles et Chat entre serveurs
Articles organisés sur plusieurs plans :

  • un niveau de priorité (1 à 3)
  • une catégorie unique
  • une position dans un arbre d'articles
  • un tag système ou n'importe quelle autre classe de tags (les métas)
  • une référence à un autre article
  • un dossier virtuel (sous-menus infini)
  • une 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

SGBD additionnelle de type "NoSql" (très puissante) 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,
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).

Revenons à nos utilisateurs communs

Philum est un outil complexe et poussé.
Pour concevoir un site créatif, il faut une plateforme ouverte et dont toutes les routines sont déclinables et améliorables. Pour cela, il faut à son tour que le code suive des règles faciles à comprendre et applicables instinctivement 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, il n'y a que des bulles un peu partout.
L'apparence de simplicité est liée à un sentiment de perfection et d'exhaustivité, ce qui est difficile à obtenir. Il y a toujours un part confiée à l'utilisateur, qu'il doit apprendre lui-même.

Les Mods

Le composant principal sont les modules. Ce sont des fonctionnalités du framework. Les modules peuvent appartenir à différentes couches logicielles, soit des actions incisives, soit des algorithmes poussés.

Le module principal est le "LOAD", qui affiche les articles d'après des paramètres globaux, affinables. Ensuite pour plus d'affinité on peut juguler les variables de sortie, ou utiliser d'autres templates, ou carrément un des nombreux autres modules presque similaires, parmi lesquels les modules "articles" qui permet de rédiger une commande Sql, et de choisir un mode de mise en forme.

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 Css

Le css par défaut est automatiquement mis à jour en permanence. Il peut être supplanté à chaque mise à jour par une version avec les couleurs locales, ou devenir une fourche figée dans le temps (ce qui sera le plus souvent le cas).
Mais même là il repose encore sur le css global, moins souvent mis à jour, et qui assure le maintient technique minimal du logiciel.

L'idée principale est qu'on puisse faire évoluer ses css de façon continue car c'est ça la meilleure manière de travailler et de s'améliorer.
L'édition des styles est grandement facilitée par un éditeur original, qui sépare les couleurs des définitions. Ainsi on peut utiliser des couleurs relatives. En une minute on peut entrer dans l'éditeur, faire une modif qu'on est le seul à voir (pas les visiteurs), et la publier aussitôt.

Usage minimal

Dans son état initial le logiciel permet de publier des articles en ligne, les organiser et les présenter.
Ils seront correctement affichés sur tous les écrans, ordis ou mobiles, ce qui correspond à 90% des usages.
Il suffit de l'installer et de publier, c'est fait pour ça.

A un premier niveau de curiosité on peut modifier son design et placer des modules qui paraissent judicieux.

Un utilisateur quotidien trouvera facilement des fonctionnalités même celles dont il n'en a pas souvent besoin. Son travail consistera à ordonner l'information et parfois créer des usages, comme le fait de consacrer chaque article à un produit.

Un développeur peut écrire des plugins qui peuvent être lancés dans l'article, en pleine page, dans une popup, ou comme iframe. Les plugins peuvent s'ancrer dans le Système.

Le Desktop

Quand on pousse un peu l'usage, Philum peut se convertir en Desktop, un bureau avec des icônes d'où on lance des activités qui apparaissent dans des popups. On peut lancer le site tel qu'on l'a conçu. Ou un autre. C'est très pratique pour faire le design par exemple (affichage en temps réel), ou simplement pour proposer au visiteur de fouiller dans des répertoires virtuels, remplis des fichiers publiés par chacun des blogueurs du site.

Ces boutons qui apparaissent sur le bureau sont des objet multi-protocolaires qu'on appelle des Apps. C'est le chapitre le plus sophistiqué de Philum.
Aussi bien, à l'origine ils servent à appeler un contenu dans une iframe, autant ils peuvent ouvrir des applications (les plugins), des activités du système (modules connecteurs etc...), des menus et sous-menus.
Il y a un gestionnaire un peu primitif. Normalement on reçoit les apps système, on peut ne pas les afficher. On peut les juguler ou les décliner. En effet on peut vouloir ouvrir un article ou un dossier d'articles (ils peuvent appartenir à un dossier virtuel).
On peut vouloir un fond d'écran en dégradé aussi...

Les Apps peuvent appartenir à n'importe lequel de ces 4 contextes :

  • menu : s'affiche dans le menu admin, dans l'onglet des Apps
  • home : s'affiche dans l'onglet système (on peut y mettre des menus du site)
  • desk : s'affiche comme icône de bureau
  • boot : est lancé au démarrage de la page

En fait tout le système de menus déroulants en ajax est lié aux Apps, qui sont joignables par un connecteur.
Il y a plusieurs tables d'Apps, les systèmes, les par défaut, et celles de l'utilisateur. L'avantage de cela est d'y loger des commandes d'activités, qui n'ont plus qu'à être appelées que par leur ID, au lieu d'une somme (toujours grandissante) de paramètres à rédiger dans les connecteurs.

Présentation 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 :

[value§option:connector]

Le système des connecteurs assure l'homogénéité de la mise en forme quelle que soit la source des données et un gain de poids de 30%.
Il permet aussi l'écriture de templates ou encore de petites applis désignées par leur balise.

[hello:b]

'hello' traité par le connecteur 'bold'

[hello§param:my_plugin]

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

Voilà, et à partir d'une idée aussi simple, tout est possible !

Visitez le Tour (qui date un peu désolé)

--
voyez wiki.framasoft.info
suivez §philum_cms
lisez w41k.com
embauchez cms.philum@gmail.com