Prise en mains
Le logiciel évolue constamment, et il est conçu pour être compréhensible pendant l'usage, avec de nombreuses aides contextuelles et assistants.
Ce manuel est assez générique pour permettre à l'utilisateur de trouver rapidement ses marques.
Notes d'utilisation
Le CMS a été développé dans le cadre de la création de sites et de publications soutenues. Il doit répondre à des besoins à la fois créatifs et de rendement.
La créativité peut s'exprimer par la disposition des objets ou l'écriture de ces objets, que cela soit à
- un niveau rudimentaire (on peut écrire sont code html),
- avancé (le codeline permet d'écrire des templates),
- expert (le cbasic permet d'écrire des modules ou des connecteurs),
- dev (on peut écrire des plugins en se basant sur le noyau).
Le rendement, c'est le temps passé en mode opérationnel. Le but est d'accélérer le plus possible l'utilisation qui consiste à ajouter des articles et divers travaux de gestion, en axant le développement sur la commodité.
Le développement essaie le plus possible de raccourcir le temps qu'il faut pour prendre ses marques. Le logiciel étant assez complexe, il est néanmoins facile de s'y retrouver parce que, dès sa conception, il fonctionne par association de composants.
Pour donner une idée brève du fonctionnement :
- la config serveur détermine le calque de bases de données et le hub par défaut ;
- les paramètres globaux renvoient le nom de la table de modules à utiliser ;
- les conditions locales déterminent quels modules utiliser ;
- la structure html est générée ;
-- les articles sont générés ;
-- les templates sont appliqués ;
- la feuille css associée est appelée ;
- le résultat est envoyé.
Les connecteurs
Tout le html est remplacé par des connecteurs, parce que c'est plus élégant dans le code, ça allège le poids des pages de 30%, ça nettoie les balises redondantes, et ça permet d'ajouter des connecteurs logiciels qui sont comme des APIs, qui renvoient le rendu d'un algorithme à partir du paramètre qu'on lui a envoyé.
Par exemple :
<b>bold</b>
s'écrit :
[bold:b ]
Le paramètre envoyé au connecteur peut prendre de nombreuses formes, il peut contenir plusieurs paramètres et plusieurs sortes de paramètres, selon un petit protocole, qui permet de les lire facilement et de les écrire d'instinct.
Exemples :
| 1 | [file.jpg ] [file.mp3 ] [file.swf ] (etc...) | extensions de fichier |
| 2 | [url.com§texte ] | lien avec texte |
| 3 | [ID:video ] | vidéo (reconnaît le provider d'après l'ID) |
| 4 | [ID:read ] | autre article importé dans celui en cours d'édition |
| 5 | [img§140/100:thumb ] | miniature d'une image à une taille prédéterminée |
| 6 | [Name=entry,Email=email:formail ] | formulaire |
| 7 | [param/title/command/option:modulename:module ] [param:modulename:module] [/title//:modulename:module] [modulename:module] | connecteur qui appelle un module (notez le ":" deux fois) |
| 10 | [hour,Home:module ] | plusieurs modules |
| 11 | [param/title/command/option:modulename§button:ajax ] [ID:read§button:ajax ] | deux boutons qui renvoient un résultat en ajax |
| 12 | [param/title/command/option:modulename§button->banner:ajax ] | un bouton qui renvoie un résultat en ajax en ciblant une div |
| 13 | [cat=public~nbdays=30/déroulé des articles/cols/3:articles:articles ] | Commande d'articles : un rendu en trois colonnes des articles de la catégorie 'public', parus il y a trente jours, et on a ajouté un titre « déroulé des articles » |
| 14 | [philum_functions:microsql ] [philum_functions§1:microsql ] | un tableau de données ; le paramètre optionnel §1 spécifie la clef |
Souvent une interface fait qu'il n'y a pas à connaître l'écriture de ces commandes, mais quand même il est bon de savoir les lire.
Microsql
Énormément de données du logiciel sont volatiles,
- au niveau du système et de ses applications,
- et au niveau utilisateur, sa config autant que ses données personnelles.
Cela a permit un énorme gain de puissance de confier presque 50% des données qui apparaissent à l'écran à une base de donnée qui stocke les fichiers "en dur". Le but est d'économiser les appels à MySql.
L'admin des 'microtables' permet d'organiser, éditer, sauvegarder et échanger des tables. Toute une machinerie nommée 'microXml' permet le transport entre sites.
Les tables renferment la configuration du site, les paramètres, les données qui servent à construire la feuille css, le cache des articles, les aides contextuelles, les langues, et sont un élément essentiel de la conception des plugins.
L'utilisateur peut créer des tableaux dont il pourra ensuite obtenir des graphiques ou des données partielles, qui peuvent être appelées via un connecteur personnalisé.
Les articles
Normalement les articles sont ajoutés un à un, avec un titre et un contenu.
Après cela on affecte une catégorie, on ajoute des tags, on le lie à un autre article, directement ou topologiquement, et éventuellement on lui confère un privilège (niveau d'autorisation requit pour y accéder) ou un template (qui détermine la position et la présentation des objets).
On peut ajouter des classes de tag utilisateur, ce qui est très pratique pour isoler différentes propriétés transversales, comme le thème, le pays... On dit "transversal" car les tags permettent d'obtenir les articles qui appartiennent à d'autres catégories.
C'est ensuite seulement qu'apparaissent, dans les menus auto, les catégories. On peut en générer d'après la topologie des articles (ils sont affiliés entre eux comme parents). En général sur les CMS les gens commencent par créer des emplacements vides qu'ils iront remplir plus tard. Ici, par défaut les catégories et taxonomies sont une émergence du contenu, qui doit donc préexister. Il est toutefois possible de créer des menus et taxonomies virtuelles.
Dans l'idéal un nouvel article est importé depuis une url.
Dans ce cas la machine fait appel à des définitions de sites situées dans une base publique. Si ils n'y sont pas, il demande de remplir les champs (il faut enquêter dans le html) et ensuite tous les articles de ce site seront importés en un clic.
Beaucoup de choses se passent quand l'article est enregistré. D'abord il est convertit et standardisé au format des connecteurs. Les sauts de lignes et la ponctuation sont mis en conformité, les règles typographiques appliquées, et les images importées et renommées.
Toute une gamme de filtres permettent de supprimer des balises ciblées (en couleur ou trop grasses), de supprimer les sauts de lignes indésirables (si le message vient d'un mail ou si il y en a trop) ou d'ajouter automatiquement les indicateurs qui permettent d'avoir des renvois vers des notes de bas de pages (ça se fait en un clic).
Les filtres fonctionnent un à un, ils sont appliqués à la version enregistrée, et si on peut en appliquer plusieurs en série, il faut enregistrer le résultat précédent à chaque fois.
Les articles ne sont pas typés. Vidéo, lien, contenu, musique, un article peut contenir toutes sortes de données, y compris un site entier si vous voulez. Il peut être le réceptacle d'un template, dans lequel s'affichent des modules et des contenus relatifs.
L'idée de base c'était d'en faire le même objet que la variable magique de Flash, qui peut contenir toutes les sortes de contenus, y compris d'autres variables du même type.
La façon dont les articles sont présentés font du site un blog, un site d'infos, un site institutionnel, un forum, ou un lieu de travail collaboratif.
Il existe une énorme quantité de façons de présenter les articles.
La conception du site
Toute cette partie n'est à faire qu'une fois, ensuite de quoi le site peut évoluer graduellement. C'est juste dommage que cette partie soit la plus technique alors que l'usage courant ne requiert pas autant de connaissance.
La config
La configuration du site adapte le logiciel aux différents usages qu'on veut en faire, s'il y a des membres, des hubs, des commentaires, comment s'expriment les dates, etc.
La config dit quelle table de modules appeler.
Les restrictions sont des boutons de type off/on, plus pratiques que la config (où les paramètres sont libres), pour appliquer des règles de fonctionnement diverses, ou choisir quelle variable sera générée dans le template, au lieu d'avoir à en éditer un personnalisé pour les nombreux cas où il n'y a que cela à changer.
Les templates
Les données générées sont envoyées à des templates qui assurent la mise en forme. Ces templates sont éditables en 'codeline', un langage qui permet de créer des balises html qui ne seront affichées que si le contenu est non vide.
Les modules
Les blocs de modules sont autant de balises 'div' sur la page. Leur pagination est assurée par les css. La liste des blocs de modules est logée dans un module appartenant à un bloc 'system' (qui ne génère pas de balise div avec cet ID).
Les modules fonctionnent comme les connecteurs et beaucoup de fonctions sont partagées. Si depuis l'article on peut appeler des modules, depuis les modules on peut appeler des connecteurs.
La rédaction des paramètres des modules est plus complexe que celle des connecteurs : les paramètres de chaque module sont définis dans un éditeur.
Certains modules sont très simple (hour) d'autres sont très complexes (articles, qui permet beaucoup de modes de présentation).
Les modules sont conditionnés, on peut choisir de les voir apparaître à tel endroit du site et pas à d'autres.
Le bloc 'system' permet de spécifier les largeurs de colonnes que le constructeur de css n'est pas capable de donner avec assez de précision, de sorte à ce que les images et vidéos soient toujours à la bonne taille.
Il spécifie les templates globaux ainsi que les feuilles css à utiliser selon les conditions.
Les css
Le constructeur de css assemble un jeu de couleur avec les données d'une table de design, de manière à permettre de créer des déclinaisons d'un design.
L'éditeur est un excellent moyen d'apprendre et de comprendre les css.
Les taches les plus habituelles (couleur, bordure, background <=> état normal, lien ou hover) sont générées dans un tableau très pratique où il suffit d'assigner le numéro d'une couleur.
De cette manière seuls les attributs plus spéciaux apparaissent dans l'éditeur de chaque classe.
