Module Wiki/Cms
Ce module doit permettre de gérer le contenu de pages web. Il doit permettre de créer, modifier, supprimer des pages.
Chaque page est identifiée bien sûr par un nom, apparaissant dans l'url. Une page peut être "fille" d'une autre page, créant ainsi une hiérarchie de page (representée par l'url).
L'url d'une page (et donc son titre) pouvant changer, le cms doit pouvoir gérer automatiquement les redirections, les erreurs 404 etc. Par exemple, lorsqu'on change l'url d'une page, et si l'ancienne url est appelée, le CMS doit redirigé vers l'ancienne. (cela aide les moteurs de recherche etc..).
Le cms historise aussi le contenu des pages.
Quand une page n'existe pas, un code 404 doit être renvoyé, avec une page basée sur un template, indiquant que la page n'existe pas. Sur cette page 404, on pourrait aussi afficher une liste de page dont le chemin ressemble ? (à voir..)
À prévoir plus tard :
- système de lock
- système de gabarit de page
Dans l'idéal, le contenu de chaque page doit pouvoir suivre un système de gabarit : chaque page est un type de page. Chaque type de page est associé à un formulaire jform, à un template d'affichage, un template d'edition etc.. Cela permet d'avoir une édition beaucoup plus ergonomique et simple pour les utilisateurs, et donc d'éviter de toujours avoir qu'un seul champ texte pour le contenu, quelque soit ce qu'on veut y mettre
specs techniques
Table cms_page
| id | id numérique |
| id_parent | id de la page parente |
| fullurl | url complete (url-page-parent/url-page-parent/url-page) |
| url_name | nom de la page dans l'url (url-page) |
| type | numérique. type de la page |
| id_page_associee | selon le type |
| url_externe | |
| last_version | numéro de la dernière version |
| date_creation | |
| date_last_modif |
Type de la page :
- 0 page inexistante (id_page_associee=0)
- 1 page (page normale...id_page_associee=0)
- 2 redirection temporaire (id_page_associee contient la page vers laquelle rediriger)
- 3 redirection permanente (id_page_associee contient la page vers laquelle rediriger)
- 4 alias (id_page_associee contient la page qu'il faut afficher)
- 5 redirection externe (url_externe contient l'url)
table cms_page_content
contient l'historisation du contenu.
| id_page | (clé primaire) |
| version | (clé primaire) |
| date_creation | |
| titre | |
| url_name | |
| short_description | |
| content | |
| author_login | (login de l'auteur, null si anonymous) |
| author_name | si anonyme.. |
| author_email | si anonyme.. |
table cms_page_link
indique quelle page est liée à quelle autre. cela permet de voir les pages "orphelines", les liens qui sont liées à des pages inexistantes etc. Table à remplir lors de la sauvegarde d'une page (donc parsing wiki nécessaire)
| id_page_from | |
| id_page_to |
CMS avec différents types de pages
Dans un cms simple, une page est toujours identique : un titre, un texte. Mais il serait bien de pouvoir avoir des pages dont le contenu est plus complexe, avec differents types de champs dans le formulaire de saisie, ce qui permet de mieux controler l'affichage, de mieux présenter une page en fonction de son contenu.
Voici differentes solutions possibles.
Solution A : tout dans la même table cms_page_content
- Une table cms_page pour référencer toutes les pages, leur type etc.
- Une table cmd_page_content, contenant les différentes versions du contenu des pages, avec un champs "content" contenant les différents champs du formulaire, encapsulé dans un format xml, json ou autre.
développement à faire pour ajouter un type de page
- un formulaire
- un template view
- un template edition
- indication quels champs du formulaire sont historisés, lesquels ne sont pas
- indication quels champs du formulaire peuvent servir de critère de recherche ou ceux à indexer pour la recherche
affichage historique d'une page
select sur cms_page_content
affichage différence entre deux versions
- recupération du content des deux enregistrements
- désencapsulation des valeurs
- affichage diff de chaque valeur (titre et liste de champs, on les prends dans le jform)
moteur de recherche global
faut stocker les valeurs "cherchable" dans un moteur d'indexation..
moteur de recherche spécifique au type de page
- liste des champs critères : dans le jform ou la conf du type de page.
- la recherche : pas vraiment possible
affichage d'une version
- select sur le cms_page_content
- désencapsulation des valeurs
- utilisation du template fourni
utilisation "externe" des données (en dehors du cms, par un autre module...)
requete sql impossible, sauf un banal select, et lecture à la main du contenu
Solution B - une table pour chaque type de contenu
- une table principale cms_page pour repertorier les pages
- une table pour chaque type de page, ayant donc leurs propres champs, mais avec toutefois un certain nombre de champs obligatoire (page_id, version etc...) pour que le versionnage puisse être fait automatiquement par les classes du cms
developpement à faire pour ajouter un type de page
- un dao (doit contenir des champs prédéfinis?)
- un formulaire
- un template view
- un template edition
- un template formulaire recherche
- indiquation quels champs peuvent servir de critère de recherche ou ceux à indexer pour la recherche
- une table specifique
affichage historique
select sur cms_page_content
affichage différence entre deux versions
- recupération du content des deux enregistrements dans la table de type
- affichage diff de chaque valeur (titre et liste de champs, on les prends dans le jform)
moteur de recherche global
faut stocker les valeurs "cherchable" dans un moteur d'indexation..
moteur de recherche specifique au type de page
suffit de faire les selects qui vont bien...
affichage d'une version
- select sur le cms_page_content
- utilisation du template fourni
utilisation "externe" des données (en dehors du cms, par un autre module...)
aucune difficulté, suffit de faire les manipulations sql que l'on veut sur la table du contenu.
Solution C - gestion des types de pages dans une base RDF
Il serait aussi possible d'utiliser une base RDF pour décrire les types de pages, et stocker les données, ce qui nous donnerais une certaines souplesse, car pour ajouter un elements à un type de page, il suffirait d'ajouter un tripple ..
J'ai regardé un peu les bases de données RDF existantes. Voila celle qui me parait la mieux:
http://librdf.org/docs/storage.html
Pour un nouveau type il faut:
- décrire dans la base rdf un nouveau type (avec des triples)
- faire le template du nouveau type pour l'affichage
Pour que ce soit plus simple, il faut aussi ecrire dans la base RDF une grammaire de base, c'est a dire décrire un champs texte, un textarea, une date, etc .. on pourrait ainsi faire évoluer les elements.
Pour aller plus loins, on pourrait meme décrire un partie de l'affichage de tel ou tel type d'elements.
ex:
- un element de type date
- on lui ajoute un selecteur de date à l'affichage ...
affichage d'une version
query rdf retournant la derniere version du doc ..
Problèmes possibles
- Ou stocke t'on les images, documents attachés etc ...
- sauvegarde/restauration de la base de données ?
- gestion des droits de modification des tripples ...
