wiki:fr/drafts/modules/wikicms
developer.jelix.org is not used any more and exists only for history. Post new tickets on the Github account.
developer.jelix.org n'est plus utilisée, et existe uniquement pour son historique. Postez les nouveaux tickets sur le compte github.

Version 5 (modified by laurentj, 14 years ago) (diff)

--

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 - une table pour chaque type de contenu, mais table de versionning commune

à developper...