OviWiki - Contributions de l’utilisateur [fr]

Gestion des skins

2008-01-08T15:35:34Z

Patricia : /* Les modules */

== Améliorations nécessaires avant modification des skins ==

=== Gestion de la navigation ===

Chaque fonctionnalité devra fournir son lien pour accéder au travers du gestionnaire d'événement. La position du lien dans l'arbre pourra être modifiée avec le module sitemap. Afin de garder la compatibilité avec les anciennes versions, l'arbre du site reprendra la structure des sections.

* Administration
** Groupes
** Addon1
* Utilisateur
** Congés
** Addon1
** Gestionnaire de fichier
** Catégories de thèmes d'article
*** Catégorie 1
**** Thème 1

nouvel événement :

bab_eventBeforeSiteMapCreated

exemple d'ajout d'un lien dans l'arbre du site :

<pre>
function bab_onSiteMapItems($event) {
// $event est une instance de bab_eventBeforeSiteMapCreated
$item = $event->createItem('topic1');
$item->setPosition(array('topcat','cat1','cat2'));
$item->setLabel($topicname);
$item->setDescription($topicdescription);
$item->setLink($topicurl, 0);
$item->setLanguage('fr');
$event->addItem($item);
}
</pre>

createItem : créer un object "élément de l'arbre du site" le paramètre est le nom de l'élément qui sera utilisé pour le positionnement dans l'arbre, il doit être unique.

setPosition : le paramètre de cette fonction est un tableau qui contient le nom des éléments parents dans l'ordre de l'arborescence.

setLabel : Permet de définir le libelé du lien

setDescription : permet de définir une description (attribut title du lien)

setLink : permet de définir l'url du lien, un second paramètre optionnel permettra de définir la méthode d'ouverture du lien (nouvelle fenêtre).

setLanguage : pour que l'élément soit pris en compte dans le filtre de langue d'ovidentia

Gestion du cache :

tout l'arbre du site sera mémorisé avec tous les noeuds possibles, une fonction devra être appelée en cas de modification pour provoquer le rafraîchissement de l'arbre.
le stockage des informations de l'arbre du site sera réparti sur 5 tables :

*Structure de l'arbre : bab_sitemap
**id_node
**id_parent
**left
**right
**id_function
*table de liaison entre la fonction et le profil : bab_sitemap_function_profile
**id_function
**id_profile
*table des fonctions utilisées : bab_sitemap_functions
**id_function
**langage
**name
**url
**description
**onclick
*table des profils : bab_sitemap_profiles
**id_profile
**uid (clef unique faite avec la liste des fonctions du profil)
*Une colonne profil dans la table des utilisateurs

Un profil est un ensemble de noeuds de l'arbre disponible pour 1 ou plusieurs utilisateurs. Si plusieurs utilisateur ont le même arbre, ils ont le même profil.

Si une fonction est intégrée plusieurs fois dans l'arbre, le profil et la table de liaison restent identiques.

Liste des actions qui déclenchent la suppression des arbres de tous les utilisateurs :

*ajout d'un thème d'article
*modification des droits d'accès ACL
*Activation/désactivation d'un module
*modification de la langue du site
*Modification du skin du site
*Déplacement d'un thème
*Déplacement d'une catégorie
*Modification de l'état visible/invisible d'un répertoire partagé
*Suppression d'un répertoire partagé
*Suppression d'un thème
*Suppression d'une catégorie
*Suppression d'un forum
*Modification de l'état actif/inactif d'un forum

Liste des actions qui déclenchent la suppression de l'arbre d'un utilisateur :

*modification de la langue de l'utilisateur
*modification du skin de l'utilisateur
*l'utilisateur est ajouté dans un groupe
*l'utilisateur est supprimé d'un groupe
*la liste des instances d'approbation est recalculée
*Ajout de l'utilisateur dans le personnel des congés
*Suppression de l'utilisateur du personnel de congés

=== OVML ===

*Gestion des inclusions
*Contener pour obtenir la liste des sections ordonnées avec un filtre pour les 2 colonnes de sections (sections personnalisés)
*Contener pour lister les éléments nouveau sur le portail
*Contener pour afficher un calendrier avec les événements d'agenda du mois en cours
*Contener pour afficher un niveau de l'arbre du site
*Variable pour l'email de l'administrateur
*Permettre la récupération des thèmes d'articles avec une variable qui définit si il y a des articles en attente d'approbation (à confirmer)
*Dans le contener de la liste des forums, il faut une variable avec le nombre de contributions en attente (à confirmer)
*Contener pour le contenu du menu ovidentia groupware
*Pour chaque article, avoir une url de modification si l'utilisateur a les droits de modification

== Nouvelle gestion des skins ==

=== Templates ===

Les templates ne seront plus modifiables en dehors du noyau, tout le travail de personnalisation devra être fait en ovml.
2 modes de gestion seront possibles :

Le mode groupware : tous les templates sont gérés par le noyau et le skin peut lui appliquer une feuille de style non prioritaire

Le mode fullpage : La page entière est un fichier ovml, tout est personnalisable mais les applications d'ovidentia ne peuvent pas être affichées dedans, seules les fonctionnalités fournies par ovml pourront être exploitées dans ce mode.

Si le mode fullpage est utilisé, un nouveau point d'entrée devra être défini dans le site, équivalent d'un « echo=1 » sur les pages ovml

=== Feuilles de style ===

En mode groupware, le skin pourra affecter une feuille de style à la page web, celle-ci sera chargée en premier, les feuilles de styles du noyau chargées de l'affichage des applications seront chargées après.
La personalisation graphique du groupware se limitera aux propriétés « background » et « color » sur certaines classes définies dans une documentation (4 ou 5 classes maximum) ainsi que la personnalisation de l'ovml chargé en bas de page.

Pour le mode fullpage, aucune spécification n'est nécessaire.

=== Fichier de configuration ===

Informations du fichier de configuration :

<pre>
name = "superskin"
version = "1.0"
ov_version = "5.9.0"
thumbnail = "images/preview.jpg"
ovml_groupware = "ovml/groupware.html"
ovml_groupware_home = "ovml/groupware.html"
css_groupware = "styles/customgroupware.css"
ovml_fullpage = "ovml/fullpage.html"
</pre>

Le fichier de configuration du skin devra être placé à la racine du répertoire du skin et devra être obligatoirement nommé « skin.ini »

*name : nom du skin visible par l'interface d'ovidentia
*version : version du skin pour permettre les chargements de nouvelles versions par zip
*ov_version : version minimale d'ovidentia nécessaire
*thumbnail : image miniature du skin qui sera affichée dans l'interface d'ovidentia
*ovml_groupware : permet de charger un fichier ovml sur l'interface groupware en bas de page
*ovml_groupware_home : le fichier ovml qui sera chargé lors de l'affichage de la page d'accueil du groupware
*css_groupware : feuille de style du skin chargée en premier dans l'interface groupware
*ovml_fullpage :

=== Spécificités du mode groupware ===

Les applications web créées dans Ovidentia pour le mode groupware seront toujours dans un élément en position absolue.

Par défaut, $babBody->babecho permettra de mettre une application dans la partie contenue, la position absolue permettra de contrôler la position exacte. Un élément placé en top:0 et left:0 se vera positionné dans le cadre prévu à cet effet par la feuille de style « groupware » définie dans le noyau.

Un menu déroulant qui reprend l'arbre du site sera disponible dans le mode groupware pour les fonctionnalités d'Ovidentia

=== Gestion dynamiques des sections ===

Le nouveau système de section sera utilisé par les applications pour générer des sections contextuelles. Par exemple, une section de calendrier dans l'agenda ou une section de liste de thème dans l'affichage des articles.

Une Api php permettra au developpeur d'ajouter ces propres sections et aussi de désactiver les sections utilisteurs pour une page donnée(forcer le mode pleine page).

=== Gestion des skins ===

Une interface dans Ovidentia sera prévue pour gérer les skins de la même façon que les modules d'Ovidentia, la liste des skins disponibles affichera l'image configurée dans « thumbnail » du fichier de configuration.

== Migration ==

=== Contraintes ===

Dans certains cas, il sera impossible de reproduire un skin à l'identique, chaque application Ovidentia pourra être affichée en suivant les contraintes du mode « groupware ». Si le niveau de personnalisation du mode groupware ne suffit plus pour une application, il faudra enrichir l'api ovml pour que l'application cernée fournisse le même niveau de fonctionnalité pour le mode « fullpage »

=== Mode opératoire ===

Convertir tous les fichiers template d'un skin en équivalent ovml pour le mode fullpage.
Créer la feuille de style pour le mode groupware si des applications sont utilisées (intranet extranet)

=== Les modules ===

Les modules continuent à fonctionner à l'identique, ils devront fournir leur api ovml pour être utilisés dans le mode fullpage

Gestion des skins

2008-01-08T15:35:07Z

Patricia : /* Mode opératoire */

== Améliorations nécessaires avant modification des skins ==

=== Gestion de la navigation ===

Chaque fonctionnalité devra fournir son lien pour accéder au travers du gestionnaire d'événement. La position du lien dans l'arbre pourra être modifiée avec le module sitemap. Afin de garder la compatibilité avec les anciennes versions, l'arbre du site reprendra la structure des sections.

* Administration
** Groupes
** Addon1
* Utilisateur
** Congés
** Addon1
** Gestionnaire de fichier
** Catégories de thèmes d'article
*** Catégorie 1
**** Thème 1

nouvel événement :

bab_eventBeforeSiteMapCreated

exemple d'ajout d'un lien dans l'arbre du site :

<pre>
function bab_onSiteMapItems($event) {
// $event est une instance de bab_eventBeforeSiteMapCreated
$item = $event->createItem('topic1');
$item->setPosition(array('topcat','cat1','cat2'));
$item->setLabel($topicname);
$item->setDescription($topicdescription);
$item->setLink($topicurl, 0);
$item->setLanguage('fr');
$event->addItem($item);
}
</pre>

createItem : créer un object "élément de l'arbre du site" le paramètre est le nom de l'élément qui sera utilisé pour le positionnement dans l'arbre, il doit être unique.

setPosition : le paramètre de cette fonction est un tableau qui contient le nom des éléments parents dans l'ordre de l'arborescence.

setLabel : Permet de définir le libelé du lien

setDescription : permet de définir une description (attribut title du lien)

setLink : permet de définir l'url du lien, un second paramètre optionnel permettra de définir la méthode d'ouverture du lien (nouvelle fenêtre).

setLanguage : pour que l'élément soit pris en compte dans le filtre de langue d'ovidentia

Gestion du cache :

tout l'arbre du site sera mémorisé avec tous les noeuds possibles, une fonction devra être appelée en cas de modification pour provoquer le rafraîchissement de l'arbre.
le stockage des informations de l'arbre du site sera réparti sur 5 tables :

*Structure de l'arbre : bab_sitemap
**id_node
**id_parent
**left
**right
**id_function
*table de liaison entre la fonction et le profil : bab_sitemap_function_profile
**id_function
**id_profile
*table des fonctions utilisées : bab_sitemap_functions
**id_function
**langage
**name
**url
**description
**onclick
*table des profils : bab_sitemap_profiles
**id_profile
**uid (clef unique faite avec la liste des fonctions du profil)
*Une colonne profil dans la table des utilisateurs

Un profil est un ensemble de noeuds de l'arbre disponible pour 1 ou plusieurs utilisateurs. Si plusieurs utilisateur ont le même arbre, ils ont le même profil.

Si une fonction est intégrée plusieurs fois dans l'arbre, le profil et la table de liaison restent identiques.

Liste des actions qui déclenchent la suppression des arbres de tous les utilisateurs :

*ajout d'un thème d'article
*modification des droits d'accès ACL
*Activation/désactivation d'un module
*modification de la langue du site
*Modification du skin du site
*Déplacement d'un thème
*Déplacement d'une catégorie
*Modification de l'état visible/invisible d'un répertoire partagé
*Suppression d'un répertoire partagé
*Suppression d'un thème
*Suppression d'une catégorie
*Suppression d'un forum
*Modification de l'état actif/inactif d'un forum

Liste des actions qui déclenchent la suppression de l'arbre d'un utilisateur :

*modification de la langue de l'utilisateur
*modification du skin de l'utilisateur
*l'utilisateur est ajouté dans un groupe
*l'utilisateur est supprimé d'un groupe
*la liste des instances d'approbation est recalculée
*Ajout de l'utilisateur dans le personnel des congés
*Suppression de l'utilisateur du personnel de congés

=== OVML ===

*Gestion des inclusions
*Contener pour obtenir la liste des sections ordonnées avec un filtre pour les 2 colonnes de sections (sections personnalisés)
*Contener pour lister les éléments nouveau sur le portail
*Contener pour afficher un calendrier avec les événements d'agenda du mois en cours
*Contener pour afficher un niveau de l'arbre du site
*Variable pour l'email de l'administrateur
*Permettre la récupération des thèmes d'articles avec une variable qui définit si il y a des articles en attente d'approbation (à confirmer)
*Dans le contener de la liste des forums, il faut une variable avec le nombre de contributions en attente (à confirmer)
*Contener pour le contenu du menu ovidentia groupware
*Pour chaque article, avoir une url de modification si l'utilisateur a les droits de modification

== Nouvelle gestion des skins ==

=== Templates ===

Les templates ne seront plus modifiables en dehors du noyau, tout le travail de personnalisation devra être fait en ovml.
2 modes de gestion seront possibles :

Le mode groupware : tous les templates sont gérés par le noyau et le skin peut lui appliquer une feuille de style non prioritaire

Le mode fullpage : La page entière est un fichier ovml, tout est personnalisable mais les applications d'ovidentia ne peuvent pas être affichées dedans, seules les fonctionnalités fournies par ovml pourront être exploitées dans ce mode.

Si le mode fullpage est utilisé, un nouveau point d'entrée devra être défini dans le site, équivalent d'un « echo=1 » sur les pages ovml

=== Feuilles de style ===

En mode groupware, le skin pourra affecter une feuille de style à la page web, celle-ci sera chargée en premier, les feuilles de styles du noyau chargées de l'affichage des applications seront chargées après.
La personalisation graphique du groupware se limitera aux propriétés « background » et « color » sur certaines classes définies dans une documentation (4 ou 5 classes maximum) ainsi que la personnalisation de l'ovml chargé en bas de page.

Pour le mode fullpage, aucune spécification n'est nécessaire.

=== Fichier de configuration ===

Informations du fichier de configuration :

<pre>
name = "superskin"
version = "1.0"
ov_version = "5.9.0"
thumbnail = "images/preview.jpg"
ovml_groupware = "ovml/groupware.html"
ovml_groupware_home = "ovml/groupware.html"
css_groupware = "styles/customgroupware.css"
ovml_fullpage = "ovml/fullpage.html"
</pre>

Le fichier de configuration du skin devra être placé à la racine du répertoire du skin et devra être obligatoirement nommé « skin.ini »

*name : nom du skin visible par l'interface d'ovidentia
*version : version du skin pour permettre les chargements de nouvelles versions par zip
*ov_version : version minimale d'ovidentia nécessaire
*thumbnail : image miniature du skin qui sera affichée dans l'interface d'ovidentia
*ovml_groupware : permet de charger un fichier ovml sur l'interface groupware en bas de page
*ovml_groupware_home : le fichier ovml qui sera chargé lors de l'affichage de la page d'accueil du groupware
*css_groupware : feuille de style du skin chargée en premier dans l'interface groupware
*ovml_fullpage :

=== Spécificités du mode groupware ===

Les applications web créées dans Ovidentia pour le mode groupware seront toujours dans un élément en position absolue.

Par défaut, $babBody->babecho permettra de mettre une application dans la partie contenue, la position absolue permettra de contrôler la position exacte. Un élément placé en top:0 et left:0 se vera positionné dans le cadre prévu à cet effet par la feuille de style « groupware » définie dans le noyau.

Un menu déroulant qui reprend l'arbre du site sera disponible dans le mode groupware pour les fonctionnalités d'Ovidentia

=== Gestion dynamiques des sections ===

Le nouveau système de section sera utilisé par les applications pour générer des sections contextuelles. Par exemple, une section de calendrier dans l'agenda ou une section de liste de thème dans l'affichage des articles.

Une Api php permettra au developpeur d'ajouter ces propres sections et aussi de désactiver les sections utilisteurs pour une page donnée(forcer le mode pleine page).

=== Gestion des skins ===

Une interface dans Ovidentia sera prévue pour gérer les skins de la même façon que les modules d'Ovidentia, la liste des skins disponibles affichera l'image configurée dans « thumbnail » du fichier de configuration.

== Migration ==

=== Contraintes ===

Dans certains cas, il sera impossible de reproduire un skin à l'identique, chaque application Ovidentia pourra être affichée en suivant les contraintes du mode « groupware ». Si le niveau de personnalisation du mode groupware ne suffit plus pour une application, il faudra enrichir l'api ovml pour que l'application cernée fournisse le même niveau de fonctionnalité pour le mode « fullpage »

=== Mode opératoire ===

Convertir tous les fichiers template d'un skin en équivalent ovml pour le mode fullpage.
Créer la feuille de style pour le mode groupware si des applications sont utilisées (intranet extranet)

=== Les modules ===

Les modules continuent a fonctionner à l'identique, ils devrons fournir leur api ovml pour être utilisés dans le mode fullpage

Gestion des skins

2008-01-08T15:34:36Z

Patricia : /* Contraintes */

== Améliorations nécessaires avant modification des skins ==

=== Gestion de la navigation ===

Chaque fonctionnalité devra fournir son lien pour accéder au travers du gestionnaire d'événement. La position du lien dans l'arbre pourra être modifiée avec le module sitemap. Afin de garder la compatibilité avec les anciennes versions, l'arbre du site reprendra la structure des sections.

* Administration
** Groupes
** Addon1
* Utilisateur
** Congés
** Addon1
** Gestionnaire de fichier
** Catégories de thèmes d'article
*** Catégorie 1
**** Thème 1

nouvel événement :

bab_eventBeforeSiteMapCreated

exemple d'ajout d'un lien dans l'arbre du site :

<pre>
function bab_onSiteMapItems($event) {
// $event est une instance de bab_eventBeforeSiteMapCreated
$item = $event->createItem('topic1');
$item->setPosition(array('topcat','cat1','cat2'));
$item->setLabel($topicname);
$item->setDescription($topicdescription);
$item->setLink($topicurl, 0);
$item->setLanguage('fr');
$event->addItem($item);
}
</pre>

createItem : créer un object "élément de l'arbre du site" le paramètre est le nom de l'élément qui sera utilisé pour le positionnement dans l'arbre, il doit être unique.

setPosition : le paramètre de cette fonction est un tableau qui contient le nom des éléments parents dans l'ordre de l'arborescence.

setLabel : Permet de définir le libelé du lien

setDescription : permet de définir une description (attribut title du lien)

setLink : permet de définir l'url du lien, un second paramètre optionnel permettra de définir la méthode d'ouverture du lien (nouvelle fenêtre).

setLanguage : pour que l'élément soit pris en compte dans le filtre de langue d'ovidentia

Gestion du cache :

tout l'arbre du site sera mémorisé avec tous les noeuds possibles, une fonction devra être appelée en cas de modification pour provoquer le rafraîchissement de l'arbre.
le stockage des informations de l'arbre du site sera réparti sur 5 tables :

*Structure de l'arbre : bab_sitemap
**id_node
**id_parent
**left
**right
**id_function
*table de liaison entre la fonction et le profil : bab_sitemap_function_profile
**id_function
**id_profile
*table des fonctions utilisées : bab_sitemap_functions
**id_function
**langage
**name
**url
**description
**onclick
*table des profils : bab_sitemap_profiles
**id_profile
**uid (clef unique faite avec la liste des fonctions du profil)
*Une colonne profil dans la table des utilisateurs

Un profil est un ensemble de noeuds de l'arbre disponible pour 1 ou plusieurs utilisateurs. Si plusieurs utilisateur ont le même arbre, ils ont le même profil.

Si une fonction est intégrée plusieurs fois dans l'arbre, le profil et la table de liaison restent identiques.

Liste des actions qui déclenchent la suppression des arbres de tous les utilisateurs :

*ajout d'un thème d'article
*modification des droits d'accès ACL
*Activation/désactivation d'un module
*modification de la langue du site
*Modification du skin du site
*Déplacement d'un thème
*Déplacement d'une catégorie
*Modification de l'état visible/invisible d'un répertoire partagé
*Suppression d'un répertoire partagé
*Suppression d'un thème
*Suppression d'une catégorie
*Suppression d'un forum
*Modification de l'état actif/inactif d'un forum

Liste des actions qui déclenchent la suppression de l'arbre d'un utilisateur :

*modification de la langue de l'utilisateur
*modification du skin de l'utilisateur
*l'utilisateur est ajouté dans un groupe
*l'utilisateur est supprimé d'un groupe
*la liste des instances d'approbation est recalculée
*Ajout de l'utilisateur dans le personnel des congés
*Suppression de l'utilisateur du personnel de congés

=== OVML ===

*Gestion des inclusions
*Contener pour obtenir la liste des sections ordonnées avec un filtre pour les 2 colonnes de sections (sections personnalisés)
*Contener pour lister les éléments nouveau sur le portail
*Contener pour afficher un calendrier avec les événements d'agenda du mois en cours
*Contener pour afficher un niveau de l'arbre du site
*Variable pour l'email de l'administrateur
*Permettre la récupération des thèmes d'articles avec une variable qui définit si il y a des articles en attente d'approbation (à confirmer)
*Dans le contener de la liste des forums, il faut une variable avec le nombre de contributions en attente (à confirmer)
*Contener pour le contenu du menu ovidentia groupware
*Pour chaque article, avoir une url de modification si l'utilisateur a les droits de modification

== Nouvelle gestion des skins ==

=== Templates ===

Les templates ne seront plus modifiables en dehors du noyau, tout le travail de personnalisation devra être fait en ovml.
2 modes de gestion seront possibles :

Le mode groupware : tous les templates sont gérés par le noyau et le skin peut lui appliquer une feuille de style non prioritaire

Le mode fullpage : La page entière est un fichier ovml, tout est personnalisable mais les applications d'ovidentia ne peuvent pas être affichées dedans, seules les fonctionnalités fournies par ovml pourront être exploitées dans ce mode.

Si le mode fullpage est utilisé, un nouveau point d'entrée devra être défini dans le site, équivalent d'un « echo=1 » sur les pages ovml

=== Feuilles de style ===

En mode groupware, le skin pourra affecter une feuille de style à la page web, celle-ci sera chargée en premier, les feuilles de styles du noyau chargées de l'affichage des applications seront chargées après.
La personalisation graphique du groupware se limitera aux propriétés « background » et « color » sur certaines classes définies dans une documentation (4 ou 5 classes maximum) ainsi que la personnalisation de l'ovml chargé en bas de page.

Pour le mode fullpage, aucune spécification n'est nécessaire.

=== Fichier de configuration ===

Informations du fichier de configuration :

<pre>
name = "superskin"
version = "1.0"
ov_version = "5.9.0"
thumbnail = "images/preview.jpg"
ovml_groupware = "ovml/groupware.html"
ovml_groupware_home = "ovml/groupware.html"
css_groupware = "styles/customgroupware.css"
ovml_fullpage = "ovml/fullpage.html"
</pre>

Le fichier de configuration du skin devra être placé à la racine du répertoire du skin et devra être obligatoirement nommé « skin.ini »

*name : nom du skin visible par l'interface d'ovidentia
*version : version du skin pour permettre les chargements de nouvelles versions par zip
*ov_version : version minimale d'ovidentia nécessaire
*thumbnail : image miniature du skin qui sera affichée dans l'interface d'ovidentia
*ovml_groupware : permet de charger un fichier ovml sur l'interface groupware en bas de page
*ovml_groupware_home : le fichier ovml qui sera chargé lors de l'affichage de la page d'accueil du groupware
*css_groupware : feuille de style du skin chargée en premier dans l'interface groupware
*ovml_fullpage :

=== Spécificités du mode groupware ===

Les applications web créées dans Ovidentia pour le mode groupware seront toujours dans un élément en position absolue.

Par défaut, $babBody->babecho permettra de mettre une application dans la partie contenue, la position absolue permettra de contrôler la position exacte. Un élément placé en top:0 et left:0 se vera positionné dans le cadre prévu à cet effet par la feuille de style « groupware » définie dans le noyau.

Un menu déroulant qui reprend l'arbre du site sera disponible dans le mode groupware pour les fonctionnalités d'Ovidentia

=== Gestion dynamiques des sections ===

Le nouveau système de section sera utilisé par les applications pour générer des sections contextuelles. Par exemple, une section de calendrier dans l'agenda ou une section de liste de thème dans l'affichage des articles.

Une Api php permettra au developpeur d'ajouter ces propres sections et aussi de désactiver les sections utilisteurs pour une page donnée(forcer le mode pleine page).

=== Gestion des skins ===

Une interface dans Ovidentia sera prévue pour gérer les skins de la même façon que les modules d'Ovidentia, la liste des skins disponibles affichera l'image configurée dans « thumbnail » du fichier de configuration.

== Migration ==

=== Contraintes ===

Dans certains cas, il sera impossible de reproduire un skin à l'identique, chaque application Ovidentia pourra être affichée en suivant les contraintes du mode « groupware ». Si le niveau de personnalisation du mode groupware ne suffit plus pour une application, il faudra enrichir l'api ovml pour que l'application cernée fournisse le même niveau de fonctionnalité pour le mode « fullpage »

=== Mode opératoire ===

Convertir tout les fichier template d'un skin en équivalent ovml pour le mode fullpage
Créer la feuille de style pour le mode groupware si des application sont utilisée (intranet extranet)

=== Les modules ===

Les modules continuent a fonctionner à l'identique, ils devrons fournir leur api ovml pour être utilisés dans le mode fullpage

Gestion des skins

2008-01-08T15:33:56Z

Patricia : /* Gestion des skins */

== Améliorations nécessaires avant modification des skins ==

=== Gestion de la navigation ===

Chaque fonctionnalité devra fournir son lien pour accéder au travers du gestionnaire d'événement. La position du lien dans l'arbre pourra être modifiée avec le module sitemap. Afin de garder la compatibilité avec les anciennes versions, l'arbre du site reprendra la structure des sections.

* Administration
** Groupes
** Addon1
* Utilisateur
** Congés
** Addon1
** Gestionnaire de fichier
** Catégories de thèmes d'article
*** Catégorie 1
**** Thème 1

nouvel événement :

bab_eventBeforeSiteMapCreated

exemple d'ajout d'un lien dans l'arbre du site :

<pre>
function bab_onSiteMapItems($event) {
// $event est une instance de bab_eventBeforeSiteMapCreated
$item = $event->createItem('topic1');
$item->setPosition(array('topcat','cat1','cat2'));
$item->setLabel($topicname);
$item->setDescription($topicdescription);
$item->setLink($topicurl, 0);
$item->setLanguage('fr');
$event->addItem($item);
}
</pre>

createItem : créer un object "élément de l'arbre du site" le paramètre est le nom de l'élément qui sera utilisé pour le positionnement dans l'arbre, il doit être unique.

setPosition : le paramètre de cette fonction est un tableau qui contient le nom des éléments parents dans l'ordre de l'arborescence.

setLabel : Permet de définir le libelé du lien

setDescription : permet de définir une description (attribut title du lien)

setLink : permet de définir l'url du lien, un second paramètre optionnel permettra de définir la méthode d'ouverture du lien (nouvelle fenêtre).

setLanguage : pour que l'élément soit pris en compte dans le filtre de langue d'ovidentia

Gestion du cache :

tout l'arbre du site sera mémorisé avec tous les noeuds possibles, une fonction devra être appelée en cas de modification pour provoquer le rafraîchissement de l'arbre.
le stockage des informations de l'arbre du site sera réparti sur 5 tables :

*Structure de l'arbre : bab_sitemap
**id_node
**id_parent
**left
**right
**id_function
*table de liaison entre la fonction et le profil : bab_sitemap_function_profile
**id_function
**id_profile
*table des fonctions utilisées : bab_sitemap_functions
**id_function
**langage
**name
**url
**description
**onclick
*table des profils : bab_sitemap_profiles
**id_profile
**uid (clef unique faite avec la liste des fonctions du profil)
*Une colonne profil dans la table des utilisateurs

Un profil est un ensemble de noeuds de l'arbre disponible pour 1 ou plusieurs utilisateurs. Si plusieurs utilisateur ont le même arbre, ils ont le même profil.

Si une fonction est intégrée plusieurs fois dans l'arbre, le profil et la table de liaison restent identiques.

Liste des actions qui déclenchent la suppression des arbres de tous les utilisateurs :

*ajout d'un thème d'article
*modification des droits d'accès ACL
*Activation/désactivation d'un module
*modification de la langue du site
*Modification du skin du site
*Déplacement d'un thème
*Déplacement d'une catégorie
*Modification de l'état visible/invisible d'un répertoire partagé
*Suppression d'un répertoire partagé
*Suppression d'un thème
*Suppression d'une catégorie
*Suppression d'un forum
*Modification de l'état actif/inactif d'un forum

Liste des actions qui déclenchent la suppression de l'arbre d'un utilisateur :

*modification de la langue de l'utilisateur
*modification du skin de l'utilisateur
*l'utilisateur est ajouté dans un groupe
*l'utilisateur est supprimé d'un groupe
*la liste des instances d'approbation est recalculée
*Ajout de l'utilisateur dans le personnel des congés
*Suppression de l'utilisateur du personnel de congés

=== OVML ===

*Gestion des inclusions
*Contener pour obtenir la liste des sections ordonnées avec un filtre pour les 2 colonnes de sections (sections personnalisés)
*Contener pour lister les éléments nouveau sur le portail
*Contener pour afficher un calendrier avec les événements d'agenda du mois en cours
*Contener pour afficher un niveau de l'arbre du site
*Variable pour l'email de l'administrateur
*Permettre la récupération des thèmes d'articles avec une variable qui définit si il y a des articles en attente d'approbation (à confirmer)
*Dans le contener de la liste des forums, il faut une variable avec le nombre de contributions en attente (à confirmer)
*Contener pour le contenu du menu ovidentia groupware
*Pour chaque article, avoir une url de modification si l'utilisateur a les droits de modification

== Nouvelle gestion des skins ==

=== Templates ===

Les templates ne seront plus modifiables en dehors du noyau, tout le travail de personnalisation devra être fait en ovml.
2 modes de gestion seront possibles :

Le mode groupware : tous les templates sont gérés par le noyau et le skin peut lui appliquer une feuille de style non prioritaire

Le mode fullpage : La page entière est un fichier ovml, tout est personnalisable mais les applications d'ovidentia ne peuvent pas être affichées dedans, seules les fonctionnalités fournies par ovml pourront être exploitées dans ce mode.

Si le mode fullpage est utilisé, un nouveau point d'entrée devra être défini dans le site, équivalent d'un « echo=1 » sur les pages ovml

=== Feuilles de style ===

En mode groupware, le skin pourra affecter une feuille de style à la page web, celle-ci sera chargée en premier, les feuilles de styles du noyau chargées de l'affichage des applications seront chargées après.
La personalisation graphique du groupware se limitera aux propriétés « background » et « color » sur certaines classes définies dans une documentation (4 ou 5 classes maximum) ainsi que la personnalisation de l'ovml chargé en bas de page.

Pour le mode fullpage, aucune spécification n'est nécessaire.

=== Fichier de configuration ===

Informations du fichier de configuration :

<pre>
name = "superskin"
version = "1.0"
ov_version = "5.9.0"
thumbnail = "images/preview.jpg"
ovml_groupware = "ovml/groupware.html"
ovml_groupware_home = "ovml/groupware.html"
css_groupware = "styles/customgroupware.css"
ovml_fullpage = "ovml/fullpage.html"
</pre>

Le fichier de configuration du skin devra être placé à la racine du répertoire du skin et devra être obligatoirement nommé « skin.ini »

*name : nom du skin visible par l'interface d'ovidentia
*version : version du skin pour permettre les chargements de nouvelles versions par zip
*ov_version : version minimale d'ovidentia nécessaire
*thumbnail : image miniature du skin qui sera affichée dans l'interface d'ovidentia
*ovml_groupware : permet de charger un fichier ovml sur l'interface groupware en bas de page
*ovml_groupware_home : le fichier ovml qui sera chargé lors de l'affichage de la page d'accueil du groupware
*css_groupware : feuille de style du skin chargée en premier dans l'interface groupware
*ovml_fullpage :

=== Spécificités du mode groupware ===

Les applications web créées dans Ovidentia pour le mode groupware seront toujours dans un élément en position absolue.

Par défaut, $babBody->babecho permettra de mettre une application dans la partie contenue, la position absolue permettra de contrôler la position exacte. Un élément placé en top:0 et left:0 se vera positionné dans le cadre prévu à cet effet par la feuille de style « groupware » définie dans le noyau.

Un menu déroulant qui reprend l'arbre du site sera disponible dans le mode groupware pour les fonctionnalités d'Ovidentia

=== Gestion dynamiques des sections ===

Le nouveau système de section sera utilisé par les applications pour générer des sections contextuelles. Par exemple, une section de calendrier dans l'agenda ou une section de liste de thème dans l'affichage des articles.

Une Api php permettra au developpeur d'ajouter ces propres sections et aussi de désactiver les sections utilisteurs pour une page donnée(forcer le mode pleine page).

=== Gestion des skins ===

Une interface dans Ovidentia sera prévue pour gérer les skins de la même façon que les modules d'Ovidentia, la liste des skins disponibles affichera l'image configurée dans « thumbnail » du fichier de configuration.

== Migration ==

=== Contraintes ===

Dans certains cas il sera impossible de reproduire un skin à l'identique, chaque application ovidentia pourra être affichée en suivant les contraintes du mode « groupware ». Si le niveau de personnalisation du mode groupware ne suffi plus pour une application, il faudra enrichir l'api ovml pour que l'application cernée fournisse le même niveau de fonctionnalité pour le mode « fullpage »

=== Mode opératoire ===

Convertir tout les fichier template d'un skin en équivalent ovml pour le mode fullpage
Créer la feuille de style pour le mode groupware si des application sont utilisée (intranet extranet)

=== Les modules ===

Les modules continuent a fonctionner à l'identique, ils devrons fournir leur api ovml pour être utilisés dans le mode fullpage

Gestion des skins

2008-01-08T15:33:32Z

Patricia : /* Gestion dynamiques des sections */

== Améliorations nécessaires avant modification des skins ==

=== Gestion de la navigation ===

Chaque fonctionnalité devra fournir son lien pour accéder au travers du gestionnaire d'événement. La position du lien dans l'arbre pourra être modifiée avec le module sitemap. Afin de garder la compatibilité avec les anciennes versions, l'arbre du site reprendra la structure des sections.

* Administration
** Groupes
** Addon1
* Utilisateur
** Congés
** Addon1
** Gestionnaire de fichier
** Catégories de thèmes d'article
*** Catégorie 1
**** Thème 1

nouvel événement :

bab_eventBeforeSiteMapCreated

exemple d'ajout d'un lien dans l'arbre du site :

<pre>
function bab_onSiteMapItems($event) {
// $event est une instance de bab_eventBeforeSiteMapCreated
$item = $event->createItem('topic1');
$item->setPosition(array('topcat','cat1','cat2'));
$item->setLabel($topicname);
$item->setDescription($topicdescription);
$item->setLink($topicurl, 0);
$item->setLanguage('fr');
$event->addItem($item);
}
</pre>

createItem : créer un object "élément de l'arbre du site" le paramètre est le nom de l'élément qui sera utilisé pour le positionnement dans l'arbre, il doit être unique.

setPosition : le paramètre de cette fonction est un tableau qui contient le nom des éléments parents dans l'ordre de l'arborescence.

setLabel : Permet de définir le libelé du lien

setDescription : permet de définir une description (attribut title du lien)

setLink : permet de définir l'url du lien, un second paramètre optionnel permettra de définir la méthode d'ouverture du lien (nouvelle fenêtre).

setLanguage : pour que l'élément soit pris en compte dans le filtre de langue d'ovidentia

Gestion du cache :

tout l'arbre du site sera mémorisé avec tous les noeuds possibles, une fonction devra être appelée en cas de modification pour provoquer le rafraîchissement de l'arbre.
le stockage des informations de l'arbre du site sera réparti sur 5 tables :

*Structure de l'arbre : bab_sitemap
**id_node
**id_parent
**left
**right
**id_function
*table de liaison entre la fonction et le profil : bab_sitemap_function_profile
**id_function
**id_profile
*table des fonctions utilisées : bab_sitemap_functions
**id_function
**langage
**name
**url
**description
**onclick
*table des profils : bab_sitemap_profiles
**id_profile
**uid (clef unique faite avec la liste des fonctions du profil)
*Une colonne profil dans la table des utilisateurs

Un profil est un ensemble de noeuds de l'arbre disponible pour 1 ou plusieurs utilisateurs. Si plusieurs utilisateur ont le même arbre, ils ont le même profil.

Si une fonction est intégrée plusieurs fois dans l'arbre, le profil et la table de liaison restent identiques.

Liste des actions qui déclenchent la suppression des arbres de tous les utilisateurs :

*ajout d'un thème d'article
*modification des droits d'accès ACL
*Activation/désactivation d'un module
*modification de la langue du site
*Modification du skin du site
*Déplacement d'un thème
*Déplacement d'une catégorie
*Modification de l'état visible/invisible d'un répertoire partagé
*Suppression d'un répertoire partagé
*Suppression d'un thème
*Suppression d'une catégorie
*Suppression d'un forum
*Modification de l'état actif/inactif d'un forum

Liste des actions qui déclenchent la suppression de l'arbre d'un utilisateur :

*modification de la langue de l'utilisateur
*modification du skin de l'utilisateur
*l'utilisateur est ajouté dans un groupe
*l'utilisateur est supprimé d'un groupe
*la liste des instances d'approbation est recalculée
*Ajout de l'utilisateur dans le personnel des congés
*Suppression de l'utilisateur du personnel de congés

=== OVML ===

*Gestion des inclusions
*Contener pour obtenir la liste des sections ordonnées avec un filtre pour les 2 colonnes de sections (sections personnalisés)
*Contener pour lister les éléments nouveau sur le portail
*Contener pour afficher un calendrier avec les événements d'agenda du mois en cours
*Contener pour afficher un niveau de l'arbre du site
*Variable pour l'email de l'administrateur
*Permettre la récupération des thèmes d'articles avec une variable qui définit si il y a des articles en attente d'approbation (à confirmer)
*Dans le contener de la liste des forums, il faut une variable avec le nombre de contributions en attente (à confirmer)
*Contener pour le contenu du menu ovidentia groupware
*Pour chaque article, avoir une url de modification si l'utilisateur a les droits de modification

== Nouvelle gestion des skins ==

=== Templates ===

Les templates ne seront plus modifiables en dehors du noyau, tout le travail de personnalisation devra être fait en ovml.
2 modes de gestion seront possibles :

Le mode groupware : tous les templates sont gérés par le noyau et le skin peut lui appliquer une feuille de style non prioritaire

Le mode fullpage : La page entière est un fichier ovml, tout est personnalisable mais les applications d'ovidentia ne peuvent pas être affichées dedans, seules les fonctionnalités fournies par ovml pourront être exploitées dans ce mode.

Si le mode fullpage est utilisé, un nouveau point d'entrée devra être défini dans le site, équivalent d'un « echo=1 » sur les pages ovml

=== Feuilles de style ===

En mode groupware, le skin pourra affecter une feuille de style à la page web, celle-ci sera chargée en premier, les feuilles de styles du noyau chargées de l'affichage des applications seront chargées après.
La personalisation graphique du groupware se limitera aux propriétés « background » et « color » sur certaines classes définies dans une documentation (4 ou 5 classes maximum) ainsi que la personnalisation de l'ovml chargé en bas de page.

Pour le mode fullpage, aucune spécification n'est nécessaire.

=== Fichier de configuration ===

Informations du fichier de configuration :

<pre>
name = "superskin"
version = "1.0"
ov_version = "5.9.0"
thumbnail = "images/preview.jpg"
ovml_groupware = "ovml/groupware.html"
ovml_groupware_home = "ovml/groupware.html"
css_groupware = "styles/customgroupware.css"
ovml_fullpage = "ovml/fullpage.html"
</pre>

Le fichier de configuration du skin devra être placé à la racine du répertoire du skin et devra être obligatoirement nommé « skin.ini »

*name : nom du skin visible par l'interface d'ovidentia
*version : version du skin pour permettre les chargements de nouvelles versions par zip
*ov_version : version minimale d'ovidentia nécessaire
*thumbnail : image miniature du skin qui sera affichée dans l'interface d'ovidentia
*ovml_groupware : permet de charger un fichier ovml sur l'interface groupware en bas de page
*ovml_groupware_home : le fichier ovml qui sera chargé lors de l'affichage de la page d'accueil du groupware
*css_groupware : feuille de style du skin chargée en premier dans l'interface groupware
*ovml_fullpage :

=== Spécificités du mode groupware ===

Les applications web créées dans Ovidentia pour le mode groupware seront toujours dans un élément en position absolue.

Par défaut, $babBody->babecho permettra de mettre une application dans la partie contenue, la position absolue permettra de contrôler la position exacte. Un élément placé en top:0 et left:0 se vera positionné dans le cadre prévu à cet effet par la feuille de style « groupware » définie dans le noyau.

Un menu déroulant qui reprend l'arbre du site sera disponible dans le mode groupware pour les fonctionnalités d'Ovidentia

=== Gestion dynamiques des sections ===

Le nouveau système de section sera utilisé par les applications pour générer des sections contextuelles. Par exemple, une section de calendrier dans l'agenda ou une section de liste de thème dans l'affichage des articles.

Une Api php permettra au developpeur d'ajouter ces propres sections et aussi de désactiver les sections utilisteurs pour une page donnée(forcer le mode pleine page).

=== Gestion des skins ===

Une interface dans Ovidentia sera prévue pour gérer les skins de la même façon que les modules d'ovidentia, la liste des skins disponibles affichera l'image configurée dans « thumbnail » du fichier de configuration.

== Migration ==

=== Contraintes ===

Dans certains cas il sera impossible de reproduire un skin à l'identique, chaque application ovidentia pourra être affichée en suivant les contraintes du mode « groupware ». Si le niveau de personnalisation du mode groupware ne suffi plus pour une application, il faudra enrichir l'api ovml pour que l'application cernée fournisse le même niveau de fonctionnalité pour le mode « fullpage »

=== Mode opératoire ===

Convertir tout les fichier template d'un skin en équivalent ovml pour le mode fullpage
Créer la feuille de style pour le mode groupware si des application sont utilisée (intranet extranet)

=== Les modules ===

Les modules continuent a fonctionner à l'identique, ils devrons fournir leur api ovml pour être utilisés dans le mode fullpage

Gestion des skins

2008-01-08T15:32:47Z

Patricia : /* Spécificitées du mode groupware */

== Améliorations nécessaires avant modification des skins ==

=== Gestion de la navigation ===

Chaque fonctionnalité devra fournir son lien pour accéder au travers du gestionnaire d'événement. La position du lien dans l'arbre pourra être modifiée avec le module sitemap. Afin de garder la compatibilité avec les anciennes versions, l'arbre du site reprendra la structure des sections.

* Administration
** Groupes
** Addon1
* Utilisateur
** Congés
** Addon1
** Gestionnaire de fichier
** Catégories de thèmes d'article
*** Catégorie 1
**** Thème 1

nouvel événement :

bab_eventBeforeSiteMapCreated

exemple d'ajout d'un lien dans l'arbre du site :

<pre>
function bab_onSiteMapItems($event) {
// $event est une instance de bab_eventBeforeSiteMapCreated
$item = $event->createItem('topic1');
$item->setPosition(array('topcat','cat1','cat2'));
$item->setLabel($topicname);
$item->setDescription($topicdescription);
$item->setLink($topicurl, 0);
$item->setLanguage('fr');
$event->addItem($item);
}
</pre>

createItem : créer un object "élément de l'arbre du site" le paramètre est le nom de l'élément qui sera utilisé pour le positionnement dans l'arbre, il doit être unique.

setPosition : le paramètre de cette fonction est un tableau qui contient le nom des éléments parents dans l'ordre de l'arborescence.

setLabel : Permet de définir le libelé du lien

setDescription : permet de définir une description (attribut title du lien)

setLink : permet de définir l'url du lien, un second paramètre optionnel permettra de définir la méthode d'ouverture du lien (nouvelle fenêtre).

setLanguage : pour que l'élément soit pris en compte dans le filtre de langue d'ovidentia

Gestion du cache :

tout l'arbre du site sera mémorisé avec tous les noeuds possibles, une fonction devra être appelée en cas de modification pour provoquer le rafraîchissement de l'arbre.
le stockage des informations de l'arbre du site sera réparti sur 5 tables :

*Structure de l'arbre : bab_sitemap
**id_node
**id_parent
**left
**right
**id_function
*table de liaison entre la fonction et le profil : bab_sitemap_function_profile
**id_function
**id_profile
*table des fonctions utilisées : bab_sitemap_functions
**id_function
**langage
**name
**url
**description
**onclick
*table des profils : bab_sitemap_profiles
**id_profile
**uid (clef unique faite avec la liste des fonctions du profil)
*Une colonne profil dans la table des utilisateurs

Un profil est un ensemble de noeuds de l'arbre disponible pour 1 ou plusieurs utilisateurs. Si plusieurs utilisateur ont le même arbre, ils ont le même profil.

Si une fonction est intégrée plusieurs fois dans l'arbre, le profil et la table de liaison restent identiques.

Liste des actions qui déclenchent la suppression des arbres de tous les utilisateurs :

*ajout d'un thème d'article
*modification des droits d'accès ACL
*Activation/désactivation d'un module
*modification de la langue du site
*Modification du skin du site
*Déplacement d'un thème
*Déplacement d'une catégorie
*Modification de l'état visible/invisible d'un répertoire partagé
*Suppression d'un répertoire partagé
*Suppression d'un thème
*Suppression d'une catégorie
*Suppression d'un forum
*Modification de l'état actif/inactif d'un forum

Liste des actions qui déclenchent la suppression de l'arbre d'un utilisateur :

*modification de la langue de l'utilisateur
*modification du skin de l'utilisateur
*l'utilisateur est ajouté dans un groupe
*l'utilisateur est supprimé d'un groupe
*la liste des instances d'approbation est recalculée
*Ajout de l'utilisateur dans le personnel des congés
*Suppression de l'utilisateur du personnel de congés

=== OVML ===

*Gestion des inclusions
*Contener pour obtenir la liste des sections ordonnées avec un filtre pour les 2 colonnes de sections (sections personnalisés)
*Contener pour lister les éléments nouveau sur le portail
*Contener pour afficher un calendrier avec les événements d'agenda du mois en cours
*Contener pour afficher un niveau de l'arbre du site
*Variable pour l'email de l'administrateur
*Permettre la récupération des thèmes d'articles avec une variable qui définit si il y a des articles en attente d'approbation (à confirmer)
*Dans le contener de la liste des forums, il faut une variable avec le nombre de contributions en attente (à confirmer)
*Contener pour le contenu du menu ovidentia groupware
*Pour chaque article, avoir une url de modification si l'utilisateur a les droits de modification

== Nouvelle gestion des skins ==

=== Templates ===

Les templates ne seront plus modifiables en dehors du noyau, tout le travail de personnalisation devra être fait en ovml.
2 modes de gestion seront possibles :

Le mode groupware : tous les templates sont gérés par le noyau et le skin peut lui appliquer une feuille de style non prioritaire

Le mode fullpage : La page entière est un fichier ovml, tout est personnalisable mais les applications d'ovidentia ne peuvent pas être affichées dedans, seules les fonctionnalités fournies par ovml pourront être exploitées dans ce mode.

Si le mode fullpage est utilisé, un nouveau point d'entrée devra être défini dans le site, équivalent d'un « echo=1 » sur les pages ovml

=== Feuilles de style ===

En mode groupware, le skin pourra affecter une feuille de style à la page web, celle-ci sera chargée en premier, les feuilles de styles du noyau chargées de l'affichage des applications seront chargées après.
La personalisation graphique du groupware se limitera aux propriétés « background » et « color » sur certaines classes définies dans une documentation (4 ou 5 classes maximum) ainsi que la personnalisation de l'ovml chargé en bas de page.

Pour le mode fullpage, aucune spécification n'est nécessaire.

=== Fichier de configuration ===

Informations du fichier de configuration :

<pre>
name = "superskin"
version = "1.0"
ov_version = "5.9.0"
thumbnail = "images/preview.jpg"
ovml_groupware = "ovml/groupware.html"
ovml_groupware_home = "ovml/groupware.html"
css_groupware = "styles/customgroupware.css"
ovml_fullpage = "ovml/fullpage.html"
</pre>

Le fichier de configuration du skin devra être placé à la racine du répertoire du skin et devra être obligatoirement nommé « skin.ini »

*name : nom du skin visible par l'interface d'ovidentia
*version : version du skin pour permettre les chargements de nouvelles versions par zip
*ov_version : version minimale d'ovidentia nécessaire
*thumbnail : image miniature du skin qui sera affichée dans l'interface d'ovidentia
*ovml_groupware : permet de charger un fichier ovml sur l'interface groupware en bas de page
*ovml_groupware_home : le fichier ovml qui sera chargé lors de l'affichage de la page d'accueil du groupware
*css_groupware : feuille de style du skin chargée en premier dans l'interface groupware
*ovml_fullpage :

=== Spécificités du mode groupware ===

Les applications web créées dans Ovidentia pour le mode groupware seront toujours dans un élément en position absolue.

Par défaut, $babBody->babecho permettra de mettre une application dans la partie contenue, la position absolue permettra de contrôler la position exacte. Un élément placé en top:0 et left:0 se vera positionné dans le cadre prévu à cet effet par la feuille de style « groupware » définie dans le noyau.

Un menu déroulant qui reprend l'arbre du site sera disponible dans le mode groupware pour les fonctionnalités d'Ovidentia

=== Gestion dynamiques des sections ===

Le nouveau système de section sera utilisé par les applications pour générer des sections contextuelles. Par exemple une section de calendrier dans l'agenda ou une section de liste de thème dans l'affichage des articles.

Une Api php permettra au developpeur d'ajouter ces propres sections et aussi de désactiver les sections utilisteur pour une page donnée(forcer le mode pleine page).

=== Gestion des skins ===

Une interface dans Ovidentia sera prévue pour gérer les skins de la même façon que les modules d'ovidentia, la liste des skins disponibles affichera l'image configurée dans « thumbnail » du fichier de configuration.

== Migration ==

=== Contraintes ===

Dans certains cas il sera impossible de reproduire un skin à l'identique, chaque application ovidentia pourra être affichée en suivant les contraintes du mode « groupware ». Si le niveau de personnalisation du mode groupware ne suffi plus pour une application, il faudra enrichir l'api ovml pour que l'application cernée fournisse le même niveau de fonctionnalité pour le mode « fullpage »

=== Mode opératoire ===

Convertir tout les fichier template d'un skin en équivalent ovml pour le mode fullpage
Créer la feuille de style pour le mode groupware si des application sont utilisée (intranet extranet)

=== Les modules ===

Les modules continuent a fonctionner à l'identique, ils devrons fournir leur api ovml pour être utilisés dans le mode fullpage

Gestion des skins

2008-01-08T15:31:32Z

Patricia : /* Fichier de configuration */

== Améliorations nécessaires avant modification des skins ==

=== Gestion de la navigation ===

Chaque fonctionnalité devra fournir son lien pour accéder au travers du gestionnaire d'événement. La position du lien dans l'arbre pourra être modifiée avec le module sitemap. Afin de garder la compatibilité avec les anciennes versions, l'arbre du site reprendra la structure des sections.

* Administration
** Groupes
** Addon1
* Utilisateur
** Congés
** Addon1
** Gestionnaire de fichier
** Catégories de thèmes d'article
*** Catégorie 1
**** Thème 1

nouvel événement :

bab_eventBeforeSiteMapCreated

exemple d'ajout d'un lien dans l'arbre du site :

<pre>
function bab_onSiteMapItems($event) {
// $event est une instance de bab_eventBeforeSiteMapCreated
$item = $event->createItem('topic1');
$item->setPosition(array('topcat','cat1','cat2'));
$item->setLabel($topicname);
$item->setDescription($topicdescription);
$item->setLink($topicurl, 0);
$item->setLanguage('fr');
$event->addItem($item);
}
</pre>

createItem : créer un object "élément de l'arbre du site" le paramètre est le nom de l'élément qui sera utilisé pour le positionnement dans l'arbre, il doit être unique.

setPosition : le paramètre de cette fonction est un tableau qui contient le nom des éléments parents dans l'ordre de l'arborescence.

setLabel : Permet de définir le libelé du lien

setDescription : permet de définir une description (attribut title du lien)

setLink : permet de définir l'url du lien, un second paramètre optionnel permettra de définir la méthode d'ouverture du lien (nouvelle fenêtre).

setLanguage : pour que l'élément soit pris en compte dans le filtre de langue d'ovidentia

Gestion du cache :

tout l'arbre du site sera mémorisé avec tous les noeuds possibles, une fonction devra être appelée en cas de modification pour provoquer le rafraîchissement de l'arbre.
le stockage des informations de l'arbre du site sera réparti sur 5 tables :

*Structure de l'arbre : bab_sitemap
**id_node
**id_parent
**left
**right
**id_function
*table de liaison entre la fonction et le profil : bab_sitemap_function_profile
**id_function
**id_profile
*table des fonctions utilisées : bab_sitemap_functions
**id_function
**langage
**name
**url
**description
**onclick
*table des profils : bab_sitemap_profiles
**id_profile
**uid (clef unique faite avec la liste des fonctions du profil)
*Une colonne profil dans la table des utilisateurs

Un profil est un ensemble de noeuds de l'arbre disponible pour 1 ou plusieurs utilisateurs. Si plusieurs utilisateur ont le même arbre, ils ont le même profil.

Si une fonction est intégrée plusieurs fois dans l'arbre, le profil et la table de liaison restent identiques.

Liste des actions qui déclenchent la suppression des arbres de tous les utilisateurs :

*ajout d'un thème d'article
*modification des droits d'accès ACL
*Activation/désactivation d'un module
*modification de la langue du site
*Modification du skin du site
*Déplacement d'un thème
*Déplacement d'une catégorie
*Modification de l'état visible/invisible d'un répertoire partagé
*Suppression d'un répertoire partagé
*Suppression d'un thème
*Suppression d'une catégorie
*Suppression d'un forum
*Modification de l'état actif/inactif d'un forum

Liste des actions qui déclenchent la suppression de l'arbre d'un utilisateur :

*modification de la langue de l'utilisateur
*modification du skin de l'utilisateur
*l'utilisateur est ajouté dans un groupe
*l'utilisateur est supprimé d'un groupe
*la liste des instances d'approbation est recalculée
*Ajout de l'utilisateur dans le personnel des congés
*Suppression de l'utilisateur du personnel de congés

=== OVML ===

*Gestion des inclusions
*Contener pour obtenir la liste des sections ordonnées avec un filtre pour les 2 colonnes de sections (sections personnalisés)
*Contener pour lister les éléments nouveau sur le portail
*Contener pour afficher un calendrier avec les événements d'agenda du mois en cours
*Contener pour afficher un niveau de l'arbre du site
*Variable pour l'email de l'administrateur
*Permettre la récupération des thèmes d'articles avec une variable qui définit si il y a des articles en attente d'approbation (à confirmer)
*Dans le contener de la liste des forums, il faut une variable avec le nombre de contributions en attente (à confirmer)
*Contener pour le contenu du menu ovidentia groupware
*Pour chaque article, avoir une url de modification si l'utilisateur a les droits de modification

== Nouvelle gestion des skins ==

=== Templates ===

Les templates ne seront plus modifiables en dehors du noyau, tout le travail de personnalisation devra être fait en ovml.
2 modes de gestion seront possibles :

Le mode groupware : tous les templates sont gérés par le noyau et le skin peut lui appliquer une feuille de style non prioritaire

Le mode fullpage : La page entière est un fichier ovml, tout est personnalisable mais les applications d'ovidentia ne peuvent pas être affichées dedans, seules les fonctionnalités fournies par ovml pourront être exploitées dans ce mode.

Si le mode fullpage est utilisé, un nouveau point d'entrée devra être défini dans le site, équivalent d'un « echo=1 » sur les pages ovml

=== Feuilles de style ===

En mode groupware, le skin pourra affecter une feuille de style à la page web, celle-ci sera chargée en premier, les feuilles de styles du noyau chargées de l'affichage des applications seront chargées après.
La personalisation graphique du groupware se limitera aux propriétés « background » et « color » sur certaines classes définies dans une documentation (4 ou 5 classes maximum) ainsi que la personnalisation de l'ovml chargé en bas de page.

Pour le mode fullpage, aucune spécification n'est nécessaire.

=== Fichier de configuration ===

Informations du fichier de configuration :

<pre>
name = "superskin"
version = "1.0"
ov_version = "5.9.0"
thumbnail = "images/preview.jpg"
ovml_groupware = "ovml/groupware.html"
ovml_groupware_home = "ovml/groupware.html"
css_groupware = "styles/customgroupware.css"
ovml_fullpage = "ovml/fullpage.html"
</pre>

Le fichier de configuration du skin devra être placé à la racine du répertoire du skin et devra être obligatoirement nommé « skin.ini »

*name : nom du skin visible par l'interface d'ovidentia
*version : version du skin pour permettre les chargements de nouvelles versions par zip
*ov_version : version minimale d'ovidentia nécessaire
*thumbnail : image miniature du skin qui sera affichée dans l'interface d'ovidentia
*ovml_groupware : permet de charger un fichier ovml sur l'interface groupware en bas de page
*ovml_groupware_home : le fichier ovml qui sera chargé lors de l'affichage de la page d'accueil du groupware
*css_groupware : feuille de style du skin chargée en premier dans l'interface groupware
*ovml_fullpage :

=== Spécificitées du mode groupware ===

Les applications web crées dans ovidentia pour le mode groupware serons toujours dans un élément en position absolue.

Par défaut $babBody->babecho permettra de mettre une application dans la partie contenue, la position absolue permettra de contrôler la position exacte, un élément placé en top:0 et left:0 se vera positionné dans le cadre prévu a cet effet par la feuille de style « groupware » définie dans le noyau.

Un menu déroulant qui reprend l'arbre du site sera disponible dans le mode groupware pour les fonctionnalités d'ovidentia

=== Gestion dynamiques des sections ===

Le nouveau système de section sera utilisé par les applications pour générer des sections contextuelles. Par exemple une section de calendrier dans l'agenda ou une section de liste de thème dans l'affichage des articles.

Une Api php permettra au developpeur d'ajouter ces propres sections et aussi de désactiver les sections utilisteur pour une page donnée(forcer le mode pleine page).

=== Gestion des skins ===

Une interface dans Ovidentia sera prévue pour gérer les skins de la même façon que les modules d'ovidentia, la liste des skins disponibles affichera l'image configurée dans « thumbnail » du fichier de configuration.

== Migration ==

=== Contraintes ===

Dans certains cas il sera impossible de reproduire un skin à l'identique, chaque application ovidentia pourra être affichée en suivant les contraintes du mode « groupware ». Si le niveau de personnalisation du mode groupware ne suffi plus pour une application, il faudra enrichir l'api ovml pour que l'application cernée fournisse le même niveau de fonctionnalité pour le mode « fullpage »

=== Mode opératoire ===

Convertir tout les fichier template d'un skin en équivalent ovml pour le mode fullpage
Créer la feuille de style pour le mode groupware si des application sont utilisée (intranet extranet)

=== Les modules ===

Les modules continuent a fonctionner à l'identique, ils devrons fournir leur api ovml pour être utilisés dans le mode fullpage

Gestion des skins

2008-01-08T15:30:30Z

Patricia : /* Feuilles de style */

== Améliorations nécessaires avant modification des skins ==

=== Gestion de la navigation ===

Chaque fonctionnalité devra fournir son lien pour accéder au travers du gestionnaire d'événement. La position du lien dans l'arbre pourra être modifiée avec le module sitemap. Afin de garder la compatibilité avec les anciennes versions, l'arbre du site reprendra la structure des sections.

* Administration
** Groupes
** Addon1
* Utilisateur
** Congés
** Addon1
** Gestionnaire de fichier
** Catégories de thèmes d'article
*** Catégorie 1
**** Thème 1

nouvel événement :

bab_eventBeforeSiteMapCreated

exemple d'ajout d'un lien dans l'arbre du site :

<pre>
function bab_onSiteMapItems($event) {
// $event est une instance de bab_eventBeforeSiteMapCreated
$item = $event->createItem('topic1');
$item->setPosition(array('topcat','cat1','cat2'));
$item->setLabel($topicname);
$item->setDescription($topicdescription);
$item->setLink($topicurl, 0);
$item->setLanguage('fr');
$event->addItem($item);
}
</pre>

createItem : créer un object "élément de l'arbre du site" le paramètre est le nom de l'élément qui sera utilisé pour le positionnement dans l'arbre, il doit être unique.

setPosition : le paramètre de cette fonction est un tableau qui contient le nom des éléments parents dans l'ordre de l'arborescence.

setLabel : Permet de définir le libelé du lien

setDescription : permet de définir une description (attribut title du lien)

setLink : permet de définir l'url du lien, un second paramètre optionnel permettra de définir la méthode d'ouverture du lien (nouvelle fenêtre).

setLanguage : pour que l'élément soit pris en compte dans le filtre de langue d'ovidentia

Gestion du cache :

tout l'arbre du site sera mémorisé avec tous les noeuds possibles, une fonction devra être appelée en cas de modification pour provoquer le rafraîchissement de l'arbre.
le stockage des informations de l'arbre du site sera réparti sur 5 tables :

*Structure de l'arbre : bab_sitemap
**id_node
**id_parent
**left
**right
**id_function
*table de liaison entre la fonction et le profil : bab_sitemap_function_profile
**id_function
**id_profile
*table des fonctions utilisées : bab_sitemap_functions
**id_function
**langage
**name
**url
**description
**onclick
*table des profils : bab_sitemap_profiles
**id_profile
**uid (clef unique faite avec la liste des fonctions du profil)
*Une colonne profil dans la table des utilisateurs

Un profil est un ensemble de noeuds de l'arbre disponible pour 1 ou plusieurs utilisateurs. Si plusieurs utilisateur ont le même arbre, ils ont le même profil.

Si une fonction est intégrée plusieurs fois dans l'arbre, le profil et la table de liaison restent identiques.

Liste des actions qui déclenchent la suppression des arbres de tous les utilisateurs :

*ajout d'un thème d'article
*modification des droits d'accès ACL
*Activation/désactivation d'un module
*modification de la langue du site
*Modification du skin du site
*Déplacement d'un thème
*Déplacement d'une catégorie
*Modification de l'état visible/invisible d'un répertoire partagé
*Suppression d'un répertoire partagé
*Suppression d'un thème
*Suppression d'une catégorie
*Suppression d'un forum
*Modification de l'état actif/inactif d'un forum

Liste des actions qui déclenchent la suppression de l'arbre d'un utilisateur :

*modification de la langue de l'utilisateur
*modification du skin de l'utilisateur
*l'utilisateur est ajouté dans un groupe
*l'utilisateur est supprimé d'un groupe
*la liste des instances d'approbation est recalculée
*Ajout de l'utilisateur dans le personnel des congés
*Suppression de l'utilisateur du personnel de congés

=== OVML ===

*Gestion des inclusions
*Contener pour obtenir la liste des sections ordonnées avec un filtre pour les 2 colonnes de sections (sections personnalisés)
*Contener pour lister les éléments nouveau sur le portail
*Contener pour afficher un calendrier avec les événements d'agenda du mois en cours
*Contener pour afficher un niveau de l'arbre du site
*Variable pour l'email de l'administrateur
*Permettre la récupération des thèmes d'articles avec une variable qui définit si il y a des articles en attente d'approbation (à confirmer)
*Dans le contener de la liste des forums, il faut une variable avec le nombre de contributions en attente (à confirmer)
*Contener pour le contenu du menu ovidentia groupware
*Pour chaque article, avoir une url de modification si l'utilisateur a les droits de modification

== Nouvelle gestion des skins ==

=== Templates ===

Les templates ne seront plus modifiables en dehors du noyau, tout le travail de personnalisation devra être fait en ovml.
2 modes de gestion seront possibles :

Le mode groupware : tous les templates sont gérés par le noyau et le skin peut lui appliquer une feuille de style non prioritaire

Le mode fullpage : La page entière est un fichier ovml, tout est personnalisable mais les applications d'ovidentia ne peuvent pas être affichées dedans, seules les fonctionnalités fournies par ovml pourront être exploitées dans ce mode.

Si le mode fullpage est utilisé, un nouveau point d'entrée devra être défini dans le site, équivalent d'un « echo=1 » sur les pages ovml

=== Feuilles de style ===

En mode groupware, le skin pourra affecter une feuille de style à la page web, celle-ci sera chargée en premier, les feuilles de styles du noyau chargées de l'affichage des applications seront chargées après.
La personalisation graphique du groupware se limitera aux propriétés « background » et « color » sur certaines classes définies dans une documentation (4 ou 5 classes maximum) ainsi que la personnalisation de l'ovml chargé en bas de page.

Pour le mode fullpage, aucune spécification n'est nécessaire.

=== Fichier de configuration ===

Informations du fichier de configuration :

<pre>
name = "superskin"
version = "1.0"
ov_version = "5.9.0"
thumbnail = "images/preview.jpg"
ovml_groupware = "ovml/groupware.html"
ovml_groupware_home = "ovml/groupware.html"
css_groupware = "styles/customgroupware.css"
ovml_fullpage = "ovml/fullpage.html"
</pre>

Le fichier de configuration du skin devra être placé à la racine du répertoire du skin et devra être obligatoirement nomé « skin.ini »

*name : nom du skin visible par l'interface d'ovidentia
*version : version du skin pour permettre les chargement de nouvelles versions par zip
*ov_version : version minimale d'ovidentia nécéssaire
*thumbnail : image miniature du skin qui sera affichée dans l'interface d'ovidentia
*ovml_groupware : permet de charger un fichier ovml sur l'interface groupware en bas de page
*ovml_groupware_home : le fichier ovml qui sera chargé lors de l'affichage de la page d'accueil du groupware
*css_groupware : feuille de style du skin chargée en premier dans l'interface groupware
*ovml_fullpage :

=== Spécificitées du mode groupware ===

Les applications web crées dans ovidentia pour le mode groupware serons toujours dans un élément en position absolue.

Par défaut $babBody->babecho permettra de mettre une application dans la partie contenue, la position absolue permettra de contrôler la position exacte, un élément placé en top:0 et left:0 se vera positionné dans le cadre prévu a cet effet par la feuille de style « groupware » définie dans le noyau.

Un menu déroulant qui reprend l'arbre du site sera disponible dans le mode groupware pour les fonctionnalités d'ovidentia

=== Gestion dynamiques des sections ===

Le nouveau système de section sera utilisé par les applications pour générer des sections contextuelles. Par exemple une section de calendrier dans l'agenda ou une section de liste de thème dans l'affichage des articles.

Une Api php permettra au developpeur d'ajouter ces propres sections et aussi de désactiver les sections utilisteur pour une page donnée(forcer le mode pleine page).

=== Gestion des skins ===

Une interface dans Ovidentia sera prévue pour gérer les skins de la même façon que les modules d'ovidentia, la liste des skins disponibles affichera l'image configurée dans « thumbnail » du fichier de configuration.

== Migration ==

=== Contraintes ===

Dans certains cas il sera impossible de reproduire un skin à l'identique, chaque application ovidentia pourra être affichée en suivant les contraintes du mode « groupware ». Si le niveau de personnalisation du mode groupware ne suffi plus pour une application, il faudra enrichir l'api ovml pour que l'application cernée fournisse le même niveau de fonctionnalité pour le mode « fullpage »

=== Mode opératoire ===

Convertir tout les fichier template d'un skin en équivalent ovml pour le mode fullpage
Créer la feuille de style pour le mode groupware si des application sont utilisée (intranet extranet)

=== Les modules ===

Les modules continuent a fonctionner à l'identique, ils devrons fournir leur api ovml pour être utilisés dans le mode fullpage

Gestion des skins

2008-01-08T15:28:51Z

Patricia : /* Templates */

== Améliorations nécessaires avant modification des skins ==

=== Gestion de la navigation ===

Chaque fonctionnalité devra fournir son lien pour accéder au travers du gestionnaire d'événement. La position du lien dans l'arbre pourra être modifiée avec le module sitemap. Afin de garder la compatibilité avec les anciennes versions, l'arbre du site reprendra la structure des sections.

* Administration
** Groupes
** Addon1
* Utilisateur
** Congés
** Addon1
** Gestionnaire de fichier
** Catégories de thèmes d'article
*** Catégorie 1
**** Thème 1

nouvel événement :

bab_eventBeforeSiteMapCreated

exemple d'ajout d'un lien dans l'arbre du site :

<pre>
function bab_onSiteMapItems($event) {
// $event est une instance de bab_eventBeforeSiteMapCreated
$item = $event->createItem('topic1');
$item->setPosition(array('topcat','cat1','cat2'));
$item->setLabel($topicname);
$item->setDescription($topicdescription);
$item->setLink($topicurl, 0);
$item->setLanguage('fr');
$event->addItem($item);
}
</pre>

createItem : créer un object "élément de l'arbre du site" le paramètre est le nom de l'élément qui sera utilisé pour le positionnement dans l'arbre, il doit être unique.

setPosition : le paramètre de cette fonction est un tableau qui contient le nom des éléments parents dans l'ordre de l'arborescence.

setLabel : Permet de définir le libelé du lien

setDescription : permet de définir une description (attribut title du lien)

setLink : permet de définir l'url du lien, un second paramètre optionnel permettra de définir la méthode d'ouverture du lien (nouvelle fenêtre).

setLanguage : pour que l'élément soit pris en compte dans le filtre de langue d'ovidentia

Gestion du cache :

tout l'arbre du site sera mémorisé avec tous les noeuds possibles, une fonction devra être appelée en cas de modification pour provoquer le rafraîchissement de l'arbre.
le stockage des informations de l'arbre du site sera réparti sur 5 tables :

*Structure de l'arbre : bab_sitemap
**id_node
**id_parent
**left
**right
**id_function
*table de liaison entre la fonction et le profil : bab_sitemap_function_profile
**id_function
**id_profile
*table des fonctions utilisées : bab_sitemap_functions
**id_function
**langage
**name
**url
**description
**onclick
*table des profils : bab_sitemap_profiles
**id_profile
**uid (clef unique faite avec la liste des fonctions du profil)
*Une colonne profil dans la table des utilisateurs

Un profil est un ensemble de noeuds de l'arbre disponible pour 1 ou plusieurs utilisateurs. Si plusieurs utilisateur ont le même arbre, ils ont le même profil.

Si une fonction est intégrée plusieurs fois dans l'arbre, le profil et la table de liaison restent identiques.

Liste des actions qui déclenchent la suppression des arbres de tous les utilisateurs :

*ajout d'un thème d'article
*modification des droits d'accès ACL
*Activation/désactivation d'un module
*modification de la langue du site
*Modification du skin du site
*Déplacement d'un thème
*Déplacement d'une catégorie
*Modification de l'état visible/invisible d'un répertoire partagé
*Suppression d'un répertoire partagé
*Suppression d'un thème
*Suppression d'une catégorie
*Suppression d'un forum
*Modification de l'état actif/inactif d'un forum

Liste des actions qui déclenchent la suppression de l'arbre d'un utilisateur :

*modification de la langue de l'utilisateur
*modification du skin de l'utilisateur
*l'utilisateur est ajouté dans un groupe
*l'utilisateur est supprimé d'un groupe
*la liste des instances d'approbation est recalculée
*Ajout de l'utilisateur dans le personnel des congés
*Suppression de l'utilisateur du personnel de congés

=== OVML ===

*Gestion des inclusions
*Contener pour obtenir la liste des sections ordonnées avec un filtre pour les 2 colonnes de sections (sections personnalisés)
*Contener pour lister les éléments nouveau sur le portail
*Contener pour afficher un calendrier avec les événements d'agenda du mois en cours
*Contener pour afficher un niveau de l'arbre du site
*Variable pour l'email de l'administrateur
*Permettre la récupération des thèmes d'articles avec une variable qui définit si il y a des articles en attente d'approbation (à confirmer)
*Dans le contener de la liste des forums, il faut une variable avec le nombre de contributions en attente (à confirmer)
*Contener pour le contenu du menu ovidentia groupware
*Pour chaque article, avoir une url de modification si l'utilisateur a les droits de modification

== Nouvelle gestion des skins ==

=== Templates ===

Les templates ne seront plus modifiables en dehors du noyau, tout le travail de personnalisation devra être fait en ovml.
2 modes de gestion seront possibles :

Le mode groupware : tous les templates sont gérés par le noyau et le skin peut lui appliquer une feuille de style non prioritaire

Le mode fullpage : La page entière est un fichier ovml, tout est personnalisable mais les applications d'ovidentia ne peuvent pas être affichées dedans, seules les fonctionnalités fournies par ovml pourront être exploitées dans ce mode.

Si le mode fullpage est utilisé, un nouveau point d'entrée devra être défini dans le site, équivalent d'un « echo=1 » sur les pages ovml

=== Feuilles de style ===

En mode groupware, le skin pourra affecter une feuille de style à la page web, celle-ci sera chargée en premier, les feuilles de styles du noyau chargées de l'affichage des applications serons chargées après.
La personalisation graphique du groupware se limitera aux propriétés « background » et « color » sur certaines classes définies dans une documentation (4 ou 5 classes maximum).
Ainsi que la personnalisation de l'ovml chargé en bas de page

Pour le mode fullpage, aucune spécifications nécessaires.

=== Fichier de configuration ===

Informations du fichier de configuration :

<pre>
name = "superskin"
version = "1.0"
ov_version = "5.9.0"
thumbnail = "images/preview.jpg"
ovml_groupware = "ovml/groupware.html"
ovml_groupware_home = "ovml/groupware.html"
css_groupware = "styles/customgroupware.css"
ovml_fullpage = "ovml/fullpage.html"
</pre>

Le fichier de configuration du skin devra être placé à la racine du répertoire du skin et devra être obligatoirement nomé « skin.ini »

*name : nom du skin visible par l'interface d'ovidentia
*version : version du skin pour permettre les chargement de nouvelles versions par zip
*ov_version : version minimale d'ovidentia nécéssaire
*thumbnail : image miniature du skin qui sera affichée dans l'interface d'ovidentia
*ovml_groupware : permet de charger un fichier ovml sur l'interface groupware en bas de page
*ovml_groupware_home : le fichier ovml qui sera chargé lors de l'affichage de la page d'accueil du groupware
*css_groupware : feuille de style du skin chargée en premier dans l'interface groupware
*ovml_fullpage :

=== Spécificitées du mode groupware ===

Les applications web crées dans ovidentia pour le mode groupware serons toujours dans un élément en position absolue.

Par défaut $babBody->babecho permettra de mettre une application dans la partie contenue, la position absolue permettra de contrôler la position exacte, un élément placé en top:0 et left:0 se vera positionné dans le cadre prévu a cet effet par la feuille de style « groupware » définie dans le noyau.

Un menu déroulant qui reprend l'arbre du site sera disponible dans le mode groupware pour les fonctionnalités d'ovidentia

=== Gestion dynamiques des sections ===

Le nouveau système de section sera utilisé par les applications pour générer des sections contextuelles. Par exemple une section de calendrier dans l'agenda ou une section de liste de thème dans l'affichage des articles.

Une Api php permettra au developpeur d'ajouter ces propres sections et aussi de désactiver les sections utilisteur pour une page donnée(forcer le mode pleine page).

=== Gestion des skins ===

Une interface dans Ovidentia sera prévue pour gérer les skins de la même façon que les modules d'ovidentia, la liste des skins disponibles affichera l'image configurée dans « thumbnail » du fichier de configuration.

== Migration ==

=== Contraintes ===

Dans certains cas il sera impossible de reproduire un skin à l'identique, chaque application ovidentia pourra être affichée en suivant les contraintes du mode « groupware ». Si le niveau de personnalisation du mode groupware ne suffi plus pour une application, il faudra enrichir l'api ovml pour que l'application cernée fournisse le même niveau de fonctionnalité pour le mode « fullpage »

=== Mode opératoire ===

Convertir tout les fichier template d'un skin en équivalent ovml pour le mode fullpage
Créer la feuille de style pour le mode groupware si des application sont utilisée (intranet extranet)

=== Les modules ===

Les modules continuent a fonctionner à l'identique, ils devrons fournir leur api ovml pour être utilisés dans le mode fullpage

Gestion des skins

2008-01-08T15:28:05Z

Patricia : /* Templates */

== Améliorations nécessaires avant modification des skins ==

=== Gestion de la navigation ===

Chaque fonctionnalité devra fournir son lien pour accéder au travers du gestionnaire d'événement. La position du lien dans l'arbre pourra être modifiée avec le module sitemap. Afin de garder la compatibilité avec les anciennes versions, l'arbre du site reprendra la structure des sections.

* Administration
** Groupes
** Addon1
* Utilisateur
** Congés
** Addon1
** Gestionnaire de fichier
** Catégories de thèmes d'article
*** Catégorie 1
**** Thème 1

nouvel événement :

bab_eventBeforeSiteMapCreated

exemple d'ajout d'un lien dans l'arbre du site :

<pre>
function bab_onSiteMapItems($event) {
// $event est une instance de bab_eventBeforeSiteMapCreated
$item = $event->createItem('topic1');
$item->setPosition(array('topcat','cat1','cat2'));
$item->setLabel($topicname);
$item->setDescription($topicdescription);
$item->setLink($topicurl, 0);
$item->setLanguage('fr');
$event->addItem($item);
}
</pre>

createItem : créer un object "élément de l'arbre du site" le paramètre est le nom de l'élément qui sera utilisé pour le positionnement dans l'arbre, il doit être unique.

setPosition : le paramètre de cette fonction est un tableau qui contient le nom des éléments parents dans l'ordre de l'arborescence.

setLabel : Permet de définir le libelé du lien

setDescription : permet de définir une description (attribut title du lien)

setLink : permet de définir l'url du lien, un second paramètre optionnel permettra de définir la méthode d'ouverture du lien (nouvelle fenêtre).

setLanguage : pour que l'élément soit pris en compte dans le filtre de langue d'ovidentia

Gestion du cache :

tout l'arbre du site sera mémorisé avec tous les noeuds possibles, une fonction devra être appelée en cas de modification pour provoquer le rafraîchissement de l'arbre.
le stockage des informations de l'arbre du site sera réparti sur 5 tables :

*Structure de l'arbre : bab_sitemap
**id_node
**id_parent
**left
**right
**id_function
*table de liaison entre la fonction et le profil : bab_sitemap_function_profile
**id_function
**id_profile
*table des fonctions utilisées : bab_sitemap_functions
**id_function
**langage
**name
**url
**description
**onclick
*table des profils : bab_sitemap_profiles
**id_profile
**uid (clef unique faite avec la liste des fonctions du profil)
*Une colonne profil dans la table des utilisateurs

Un profil est un ensemble de noeuds de l'arbre disponible pour 1 ou plusieurs utilisateurs. Si plusieurs utilisateur ont le même arbre, ils ont le même profil.

Si une fonction est intégrée plusieurs fois dans l'arbre, le profil et la table de liaison restent identiques.

Liste des actions qui déclenchent la suppression des arbres de tous les utilisateurs :

*ajout d'un thème d'article
*modification des droits d'accès ACL
*Activation/désactivation d'un module
*modification de la langue du site
*Modification du skin du site
*Déplacement d'un thème
*Déplacement d'une catégorie
*Modification de l'état visible/invisible d'un répertoire partagé
*Suppression d'un répertoire partagé
*Suppression d'un thème
*Suppression d'une catégorie
*Suppression d'un forum
*Modification de l'état actif/inactif d'un forum

Liste des actions qui déclenchent la suppression de l'arbre d'un utilisateur :

*modification de la langue de l'utilisateur
*modification du skin de l'utilisateur
*l'utilisateur est ajouté dans un groupe
*l'utilisateur est supprimé d'un groupe
*la liste des instances d'approbation est recalculée
*Ajout de l'utilisateur dans le personnel des congés
*Suppression de l'utilisateur du personnel de congés

=== OVML ===

*Gestion des inclusions
*Contener pour obtenir la liste des sections ordonnées avec un filtre pour les 2 colonnes de sections (sections personnalisés)
*Contener pour lister les éléments nouveau sur le portail
*Contener pour afficher un calendrier avec les événements d'agenda du mois en cours
*Contener pour afficher un niveau de l'arbre du site
*Variable pour l'email de l'administrateur
*Permettre la récupération des thèmes d'articles avec une variable qui définit si il y a des articles en attente d'approbation (à confirmer)
*Dans le contener de la liste des forums, il faut une variable avec le nombre de contributions en attente (à confirmer)
*Contener pour le contenu du menu ovidentia groupware
*Pour chaque article, avoir une url de modification si l'utilisateur a les droits de modification

== Nouvelle gestion des skins ==

=== Templates ===

Les templates ne seront plus modifiables en dehors du noyau, tout le travail de personnalisation devra être fait en ovml.
2 modes de gestion seront possibles
Le mode groupware : tous les templates sont gérés par le noyau et le skin peut lui appliquer une feuille de style non prioritaire
Le mode fullpage : La page entière est un fichier ovml, tout est personnalisable mais les applications d'ovidentia ne peuvent pas être affichées dedans, seules les fonctionnalités fournies par ovml pourront être exploitées dans ce mode.

Si le mode fullpage est utilisé, un nouveau point d'entrée devra être défini dans le site, équivalent d'un « echo=1 » sur les pages ovml

=== Feuilles de style ===

En mode groupware, le skin pourra affecter une feuille de style à la page web, celle-ci sera chargée en premier, les feuilles de styles du noyau chargées de l'affichage des applications serons chargées après.
La personalisation graphique du groupware se limitera aux propriétés « background » et « color » sur certaines classes définies dans une documentation (4 ou 5 classes maximum).
Ainsi que la personnalisation de l'ovml chargé en bas de page

Pour le mode fullpage, aucune spécifications nécessaires.

=== Fichier de configuration ===

Informations du fichier de configuration :

<pre>
name = "superskin"
version = "1.0"
ov_version = "5.9.0"
thumbnail = "images/preview.jpg"
ovml_groupware = "ovml/groupware.html"
ovml_groupware_home = "ovml/groupware.html"
css_groupware = "styles/customgroupware.css"
ovml_fullpage = "ovml/fullpage.html"
</pre>

Le fichier de configuration du skin devra être placé à la racine du répertoire du skin et devra être obligatoirement nomé « skin.ini »

*name : nom du skin visible par l'interface d'ovidentia
*version : version du skin pour permettre les chargement de nouvelles versions par zip
*ov_version : version minimale d'ovidentia nécéssaire
*thumbnail : image miniature du skin qui sera affichée dans l'interface d'ovidentia
*ovml_groupware : permet de charger un fichier ovml sur l'interface groupware en bas de page
*ovml_groupware_home : le fichier ovml qui sera chargé lors de l'affichage de la page d'accueil du groupware
*css_groupware : feuille de style du skin chargée en premier dans l'interface groupware
*ovml_fullpage :

=== Spécificitées du mode groupware ===

Les applications web crées dans ovidentia pour le mode groupware serons toujours dans un élément en position absolue.

Par défaut $babBody->babecho permettra de mettre une application dans la partie contenue, la position absolue permettra de contrôler la position exacte, un élément placé en top:0 et left:0 se vera positionné dans le cadre prévu a cet effet par la feuille de style « groupware » définie dans le noyau.

Un menu déroulant qui reprend l'arbre du site sera disponible dans le mode groupware pour les fonctionnalités d'ovidentia

=== Gestion dynamiques des sections ===

Le nouveau système de section sera utilisé par les applications pour générer des sections contextuelles. Par exemple une section de calendrier dans l'agenda ou une section de liste de thème dans l'affichage des articles.

Une Api php permettra au developpeur d'ajouter ces propres sections et aussi de désactiver les sections utilisteur pour une page donnée(forcer le mode pleine page).

=== Gestion des skins ===

Une interface dans Ovidentia sera prévue pour gérer les skins de la même façon que les modules d'ovidentia, la liste des skins disponibles affichera l'image configurée dans « thumbnail » du fichier de configuration.

== Migration ==

=== Contraintes ===

Dans certains cas il sera impossible de reproduire un skin à l'identique, chaque application ovidentia pourra être affichée en suivant les contraintes du mode « groupware ». Si le niveau de personnalisation du mode groupware ne suffi plus pour une application, il faudra enrichir l'api ovml pour que l'application cernée fournisse le même niveau de fonctionnalité pour le mode « fullpage »

=== Mode opératoire ===

Convertir tout les fichier template d'un skin en équivalent ovml pour le mode fullpage
Créer la feuille de style pour le mode groupware si des application sont utilisée (intranet extranet)

=== Les modules ===

Les modules continuent a fonctionner à l'identique, ils devrons fournir leur api ovml pour être utilisés dans le mode fullpage

Gestion des skins

2008-01-08T15:10:38Z

Patricia : /* OVML */

== Améliorations nécessaires avant modification des skins ==

=== Gestion de la navigation ===

Chaque fonctionnalité devra fournir son lien pour accéder au travers du gestionnaire d'événement. La position du lien dans l'arbre pourra être modifiée avec le module sitemap. Afin de garder la compatibilité avec les anciennes versions, l'arbre du site reprendra la structure des sections.

* Administration
** Groupes
** Addon1
* Utilisateur
** Congés
** Addon1
** Gestionnaire de fichier
** Catégories de thèmes d'article
*** Catégorie 1
**** Thème 1

nouvel événement :

bab_eventBeforeSiteMapCreated

exemple d'ajout d'un lien dans l'arbre du site :

<pre>
function bab_onSiteMapItems($event) {
// $event est une instance de bab_eventBeforeSiteMapCreated
$item = $event->createItem('topic1');
$item->setPosition(array('topcat','cat1','cat2'));
$item->setLabel($topicname);
$item->setDescription($topicdescription);
$item->setLink($topicurl, 0);
$item->setLanguage('fr');
$event->addItem($item);
}
</pre>

createItem : créer un object "élément de l'arbre du site" le paramètre est le nom de l'élément qui sera utilisé pour le positionnement dans l'arbre, il doit être unique.

setPosition : le paramètre de cette fonction est un tableau qui contient le nom des éléments parents dans l'ordre de l'arborescence.

setLabel : Permet de définir le libelé du lien

setDescription : permet de définir une description (attribut title du lien)

setLink : permet de définir l'url du lien, un second paramètre optionnel permettra de définir la méthode d'ouverture du lien (nouvelle fenêtre).

setLanguage : pour que l'élément soit pris en compte dans le filtre de langue d'ovidentia

Gestion du cache :

tout l'arbre du site sera mémorisé avec tous les noeuds possibles, une fonction devra être appelée en cas de modification pour provoquer le rafraîchissement de l'arbre.
le stockage des informations de l'arbre du site sera réparti sur 5 tables :

*Structure de l'arbre : bab_sitemap
**id_node
**id_parent
**left
**right
**id_function
*table de liaison entre la fonction et le profil : bab_sitemap_function_profile
**id_function
**id_profile
*table des fonctions utilisées : bab_sitemap_functions
**id_function
**langage
**name
**url
**description
**onclick
*table des profils : bab_sitemap_profiles
**id_profile
**uid (clef unique faite avec la liste des fonctions du profil)
*Une colonne profil dans la table des utilisateurs

Un profil est un ensemble de noeuds de l'arbre disponible pour 1 ou plusieurs utilisateurs. Si plusieurs utilisateur ont le même arbre, ils ont le même profil.

Si une fonction est intégrée plusieurs fois dans l'arbre, le profil et la table de liaison restent identiques.

Liste des actions qui déclenchent la suppression des arbres de tous les utilisateurs :

*ajout d'un thème d'article
*modification des droits d'accès ACL
*Activation/désactivation d'un module
*modification de la langue du site
*Modification du skin du site
*Déplacement d'un thème
*Déplacement d'une catégorie
*Modification de l'état visible/invisible d'un répertoire partagé
*Suppression d'un répertoire partagé
*Suppression d'un thème
*Suppression d'une catégorie
*Suppression d'un forum
*Modification de l'état actif/inactif d'un forum

Liste des actions qui déclenchent la suppression de l'arbre d'un utilisateur :

*modification de la langue de l'utilisateur
*modification du skin de l'utilisateur
*l'utilisateur est ajouté dans un groupe
*l'utilisateur est supprimé d'un groupe
*la liste des instances d'approbation est recalculée
*Ajout de l'utilisateur dans le personnel des congés
*Suppression de l'utilisateur du personnel de congés

=== OVML ===

*Gestion des inclusions
*Contener pour obtenir la liste des sections ordonnées avec un filtre pour les 2 colonnes de sections (sections personnalisés)
*Contener pour lister les éléments nouveau sur le portail
*Contener pour afficher un calendrier avec les événements d'agenda du mois en cours
*Contener pour afficher un niveau de l'arbre du site
*Variable pour l'email de l'administrateur
*Permettre la récupération des thèmes d'articles avec une variable qui définit si il y a des articles en attente d'approbation (à confirmer)
*Dans le contener de la liste des forums, il faut une variable avec le nombre de contributions en attente (à confirmer)
*Contener pour le contenu du menu ovidentia groupware
*Pour chaque article, avoir une url de modification si l'utilisateur a les droits de modification

== Nouvelle gestion des skins ==

=== Templates ===

Les templates ne serons plus modifiables en dehors du noyau, tout le travail de personalisation devra être fait en ovml.
2 modes de gestion serons possibles
le mode groupware : tout les templates sont gérés par le noyau et le skin peut lui appliquer une feuille de style non prioritaire
Le mode fullpage : La page entière est un fichier ovml, tout est personalisable mais les applications d'ovidentia ne peuvent pas être affichées dedans, seules les fonctionnalités fournies par ovml pourrons être exploitées dans ce mode.

Si le mode fullpage est utilisé un nouveau point d'entré devra être définit dans le site, équivalent d'un « echo=1 » sur les pages ovml

=== Feuilles de style ===

En mode groupware, le skin pourra affecter une feuille de style à la page web, celle-ci sera chargée en premier, les feuilles de styles du noyau chargées de l'affichage des applications serons chargées après.
La personalisation graphique du groupware se limitera aux propriétés « background » et « color » sur certaines classes définies dans une documentation (4 ou 5 classes maximum).
Ainsi que la personnalisation de l'ovml chargé en bas de page

Pour le mode fullpage, aucune spécifications nécessaires.

=== Fichier de configuration ===

Informations du fichier de configuration :

<pre>
name = "superskin"
version = "1.0"
ov_version = "5.9.0"
thumbnail = "images/preview.jpg"
ovml_groupware = "ovml/groupware.html"
ovml_groupware_home = "ovml/groupware.html"
css_groupware = "styles/customgroupware.css"
ovml_fullpage = "ovml/fullpage.html"
</pre>

Le fichier de configuration du skin devra être placé à la racine du répertoire du skin et devra être obligatoirement nomé « skin.ini »

*name : nom du skin visible par l'interface d'ovidentia
*version : version du skin pour permettre les chargement de nouvelles versions par zip
*ov_version : version minimale d'ovidentia nécéssaire
*thumbnail : image miniature du skin qui sera affichée dans l'interface d'ovidentia
*ovml_groupware : permet de charger un fichier ovml sur l'interface groupware en bas de page
*ovml_groupware_home : le fichier ovml qui sera chargé lors de l'affichage de la page d'accueil du groupware
*css_groupware : feuille de style du skin chargée en premier dans l'interface groupware
*ovml_fullpage :

=== Spécificitées du mode groupware ===

Les applications web crées dans ovidentia pour le mode groupware serons toujours dans un élément en position absolue.

Par défaut $babBody->babecho permettra de mettre une application dans la partie contenue, la position absolue permettra de contrôler la position exacte, un élément placé en top:0 et left:0 se vera positionné dans le cadre prévu a cet effet par la feuille de style « groupware » définie dans le noyau.

Un menu déroulant qui reprend l'arbre du site sera disponible dans le mode groupware pour les fonctionnalités d'ovidentia

=== Gestion dynamiques des sections ===

Le nouveau système de section sera utilisé par les applications pour générer des sections contextuelles. Par exemple une section de calendrier dans l'agenda ou une section de liste de thème dans l'affichage des articles.

Une Api php permettra au developpeur d'ajouter ces propres sections et aussi de désactiver les sections utilisteur pour une page donnée(forcer le mode pleine page).

=== Gestion des skins ===

Une interface dans Ovidentia sera prévue pour gérer les skins de la même façon que les modules d'ovidentia, la liste des skins disponibles affichera l'image configurée dans « thumbnail » du fichier de configuration.

== Migration ==

=== Contraintes ===

Dans certains cas il sera impossible de reproduire un skin à l'identique, chaque application ovidentia pourra être affichée en suivant les contraintes du mode « groupware ». Si le niveau de personnalisation du mode groupware ne suffi plus pour une application, il faudra enrichir l'api ovml pour que l'application cernée fournisse le même niveau de fonctionnalité pour le mode « fullpage »

=== Mode opératoire ===

Convertir tout les fichier template d'un skin en équivalent ovml pour le mode fullpage
Créer la feuille de style pour le mode groupware si des application sont utilisée (intranet extranet)

=== Les modules ===

Les modules continuent a fonctionner à l'identique, ils devrons fournir leur api ovml pour être utilisés dans le mode fullpage

Gestion des skins

2008-01-08T15:09:25Z

Patricia : /* Gestion de la navigation */

== Améliorations nécessaires avant modification des skins ==

=== Gestion de la navigation ===

Chaque fonctionnalité devra fournir son lien pour accéder au travers du gestionnaire d'événement. La position du lien dans l'arbre pourra être modifiée avec le module sitemap. Afin de garder la compatibilité avec les anciennes versions, l'arbre du site reprendra la structure des sections.

* Administration
** Groupes
** Addon1
* Utilisateur
** Congés
** Addon1
** Gestionnaire de fichier
** Catégories de thèmes d'article
*** Catégorie 1
**** Thème 1

nouvel événement :

bab_eventBeforeSiteMapCreated

exemple d'ajout d'un lien dans l'arbre du site :

<pre>
function bab_onSiteMapItems($event) {
// $event est une instance de bab_eventBeforeSiteMapCreated
$item = $event->createItem('topic1');
$item->setPosition(array('topcat','cat1','cat2'));
$item->setLabel($topicname);
$item->setDescription($topicdescription);
$item->setLink($topicurl, 0);
$item->setLanguage('fr');
$event->addItem($item);
}
</pre>

createItem : créer un object "élément de l'arbre du site" le paramètre est le nom de l'élément qui sera utilisé pour le positionnement dans l'arbre, il doit être unique.

setPosition : le paramètre de cette fonction est un tableau qui contient le nom des éléments parents dans l'ordre de l'arborescence.

setLabel : Permet de définir le libelé du lien

setDescription : permet de définir une description (attribut title du lien)

setLink : permet de définir l'url du lien, un second paramètre optionnel permettra de définir la méthode d'ouverture du lien (nouvelle fenêtre).

setLanguage : pour que l'élément soit pris en compte dans le filtre de langue d'ovidentia

Gestion du cache :

tout l'arbre du site sera mémorisé avec tous les noeuds possibles, une fonction devra être appelée en cas de modification pour provoquer le rafraîchissement de l'arbre.
le stockage des informations de l'arbre du site sera réparti sur 5 tables :

*Structure de l'arbre : bab_sitemap
**id_node
**id_parent
**left
**right
**id_function
*table de liaison entre la fonction et le profil : bab_sitemap_function_profile
**id_function
**id_profile
*table des fonctions utilisées : bab_sitemap_functions
**id_function
**langage
**name
**url
**description
**onclick
*table des profils : bab_sitemap_profiles
**id_profile
**uid (clef unique faite avec la liste des fonctions du profil)
*Une colonne profil dans la table des utilisateurs

Un profil est un ensemble de noeuds de l'arbre disponible pour 1 ou plusieurs utilisateurs. Si plusieurs utilisateur ont le même arbre, ils ont le même profil.

Si une fonction est intégrée plusieurs fois dans l'arbre, le profil et la table de liaison restent identiques.

Liste des actions qui déclenchent la suppression des arbres de tous les utilisateurs :

*ajout d'un thème d'article
*modification des droits d'accès ACL
*Activation/désactivation d'un module
*modification de la langue du site
*Modification du skin du site
*Déplacement d'un thème
*Déplacement d'une catégorie
*Modification de l'état visible/invisible d'un répertoire partagé
*Suppression d'un répertoire partagé
*Suppression d'un thème
*Suppression d'une catégorie
*Suppression d'un forum
*Modification de l'état actif/inactif d'un forum

Liste des actions qui déclenchent la suppression de l'arbre d'un utilisateur :

*modification de la langue de l'utilisateur
*modification du skin de l'utilisateur
*l'utilisateur est ajouté dans un groupe
*l'utilisateur est supprimé d'un groupe
*la liste des instances d'approbation est recalculée
*Ajout de l'utilisateur dans le personnel des congés
*Suppression de l'utilisateur du personnel de congés

=== OVML ===

*Gestion des inclusions
*Contener pour obtenir la liste des sections ordonnées avec un filtre pour les 2 colonnes de sections (sections personnalisés)
*Contener pour lister les éléments nouveau sur le portail
*Contener pour afficher un calendrier avec les événements d'agenda du mois en cours
*Contener pour afficher un niveau de l'arbre du site
*Variable pour l'email de l'administrateur
*Permettre la récupération des thèmes d'articles avec une variable qui définit si il y a des articles en attente d'approbation (a confirmer)
*Dans le contener de la liste des forums, il faut une variable avec le nombre de contributions en attente (a confirmer)
*Contener pour le contenu du menu ovidentia groupware
*Pour chaque article, avoir une url de modification si l'utilisateur a les droits de modification

== Nouvelle gestion des skins ==

=== Templates ===

Les templates ne serons plus modifiables en dehors du noyau, tout le travail de personalisation devra être fait en ovml.
2 modes de gestion serons possibles
le mode groupware : tout les templates sont gérés par le noyau et le skin peut lui appliquer une feuille de style non prioritaire
Le mode fullpage : La page entière est un fichier ovml, tout est personalisable mais les applications d'ovidentia ne peuvent pas être affichées dedans, seules les fonctionnalités fournies par ovml pourrons être exploitées dans ce mode.

Si le mode fullpage est utilisé un nouveau point d'entré devra être définit dans le site, équivalent d'un « echo=1 » sur les pages ovml

=== Feuilles de style ===

En mode groupware, le skin pourra affecter une feuille de style à la page web, celle-ci sera chargée en premier, les feuilles de styles du noyau chargées de l'affichage des applications serons chargées après.
La personalisation graphique du groupware se limitera aux propriétés « background » et « color » sur certaines classes définies dans une documentation (4 ou 5 classes maximum).
Ainsi que la personnalisation de l'ovml chargé en bas de page

Pour le mode fullpage, aucune spécifications nécessaires.

=== Fichier de configuration ===

Informations du fichier de configuration :

<pre>
name = "superskin"
version = "1.0"
ov_version = "5.9.0"
thumbnail = "images/preview.jpg"
ovml_groupware = "ovml/groupware.html"
ovml_groupware_home = "ovml/groupware.html"
css_groupware = "styles/customgroupware.css"
ovml_fullpage = "ovml/fullpage.html"
</pre>

Le fichier de configuration du skin devra être placé à la racine du répertoire du skin et devra être obligatoirement nomé « skin.ini »

*name : nom du skin visible par l'interface d'ovidentia
*version : version du skin pour permettre les chargement de nouvelles versions par zip
*ov_version : version minimale d'ovidentia nécéssaire
*thumbnail : image miniature du skin qui sera affichée dans l'interface d'ovidentia
*ovml_groupware : permet de charger un fichier ovml sur l'interface groupware en bas de page
*ovml_groupware_home : le fichier ovml qui sera chargé lors de l'affichage de la page d'accueil du groupware
*css_groupware : feuille de style du skin chargée en premier dans l'interface groupware
*ovml_fullpage :

=== Spécificitées du mode groupware ===

Les applications web crées dans ovidentia pour le mode groupware serons toujours dans un élément en position absolue.

Par défaut $babBody->babecho permettra de mettre une application dans la partie contenue, la position absolue permettra de contrôler la position exacte, un élément placé en top:0 et left:0 se vera positionné dans le cadre prévu a cet effet par la feuille de style « groupware » définie dans le noyau.

Un menu déroulant qui reprend l'arbre du site sera disponible dans le mode groupware pour les fonctionnalités d'ovidentia

=== Gestion dynamiques des sections ===

Le nouveau système de section sera utilisé par les applications pour générer des sections contextuelles. Par exemple une section de calendrier dans l'agenda ou une section de liste de thème dans l'affichage des articles.

Une Api php permettra au developpeur d'ajouter ces propres sections et aussi de désactiver les sections utilisteur pour une page donnée(forcer le mode pleine page).

=== Gestion des skins ===

Une interface dans Ovidentia sera prévue pour gérer les skins de la même façon que les modules d'ovidentia, la liste des skins disponibles affichera l'image configurée dans « thumbnail » du fichier de configuration.

== Migration ==

=== Contraintes ===

Dans certains cas il sera impossible de reproduire un skin à l'identique, chaque application ovidentia pourra être affichée en suivant les contraintes du mode « groupware ». Si le niveau de personnalisation du mode groupware ne suffi plus pour une application, il faudra enrichir l'api ovml pour que l'application cernée fournisse le même niveau de fonctionnalité pour le mode « fullpage »

=== Mode opératoire ===

Convertir tout les fichier template d'un skin en équivalent ovml pour le mode fullpage
Créer la feuille de style pour le mode groupware si des application sont utilisée (intranet extranet)

=== Les modules ===

Les modules continuent a fonctionner à l'identique, ils devrons fournir leur api ovml pour être utilisés dans le mode fullpage

Gestionnaire de fichiers

2008-01-08T15:03:37Z

Patricia :

* AutoAddFile de manière global actif/non actif
* AutoAddFile actif/non actif pour un répertoire
* Ajouter une interface permettant de sélectionner des répertoires à auto ajoutée au gestionnaire de fichiers
* Permettre d'éditer plusieurs éléments
* Lors de l'édition de plusieurs éléments, faire en sorte que l'affichage soit en page ou en liste
* Lors de l'édition de plusieurs éléments, permettre de choisir un éléments puis d'appliquer les mêmes modifications aux autres
* Permettre d'établir des liens symboliques sur des répertoires et des fichiers (attention aux droits)
* Edit in place
* Avoir un rail de navigation comme celui de vista
* Mettre en arbre la vue côté administration
* Mettre l'interface côté utilisateur comme le gestionnaire de vista avec la possibilité d'afficher/cacher la TreeView
* Possibilité d'afficher les éléments en thumbnail
* Mettre tous les dossiers en base de données
* Renforcer le code des SET (datamapper)
* Lister les actions possibles afin d'établir une liste d'icône

Communication entre les modules

2008-01-08T15:01:47Z

Patricia : /* Fonctions */

== Dépendances entre les modules au moment de l'installation ==

Lors de l'installation d'un module, des dépendances peuvent êtres utilisées, le nom des modules dépendants doivent être ajoutés dans le fichier addonini.php avec le numéro de version minimum nécessaire dans la section "addons" :

exemple avec le module ivdashboard qui nécessite le module client :
<pre>

[general]
name="ivdashboard"
version=6.09
description="Gestion de projets INVIVO"
db_prefix="ivd_"
ov_version=5.6.2
php_version=4.1.2
mysql_version=3.23

[addons]
clients=2.8

</pre>

== Gestionnaire d'événements et fonctionnalités ==

Pour que les différents modules puissent partager des fonctions, les développeurs pourront utiliser le [[API du gestionnaire d'événement|gestionnaire d'événements]]

[[Image:Com addons.svg]]

== API des fonctionalités ==

'''Attention, cette API sera disponible à partir de ovidentia 6.6.0'''

=== Proposer des fonctionnalités ===

Chaque fonctionnalité devra être nommée selon un "chemin", par exemple "convertHtml/toPdf/openOffice", les caractères _ sont interdis dans le chemin.

Une fonction du noyau d'ovidentia permettra d'enregistrer un fichier php en tant que fonctionnalité, le fichier devra contenir une classe PHP nommée en utilisant la même arborescence, par exemple :

<pre>
class convertHtml_toPdf_openOffice extends bab_functionality {

}

</pre>

le _ remplace le / dans le nom de la classe
l'objet devra être hérité de bab_functionality.

Au moment de l'installation ou du programme de reprise, il faut enregistrer la fonctionnalité dans ovidentia, exemple :

<pre>
include_once $GLOBALS['babInstallPath'].'utilit/functionalityincl.php';

$func = new bab_functionalities();
$func->register("convertHtml/toPdf/openOffice", $GLOBALS['babAddonUrl'].'convert.php');
</pre>

Dans Ovidentia, un fichier "link.inc" sera créé dans un arbre de répertoire avec pour contenu du code php pour inclure le fichier passé en 2ème paramètre.

==== Héritage de fonctionnalités ====

Il est possible de créer une fonctionnalité qui hérite et utilise l'interface d'une autre fonctionnalité.

exemple : le module "convert" propose une fonctionnalité pour convertir du html

<pre>

class convertHtml extends bab_functionality {
function getDescription() {
return 'convertir du html vers un autre format';
}

function getFunctionalityCallableMethods() {
return array(
'process'
);
}

function process($html) {
return NULL;
}
}

</pre>

Dans un autre module "convertToPdf", on propose de convertir du html en pdf en utilisant openOffice. Pour que la fonctionnalité soit acceptée par le programme d'installation, l'objet doit contenir au moins les méthodes du parent. La liste des méthodes sera comparée en utilisant "getFunctionalityCallableMethods".

<pre>

bab_functionality::includefile('convertHtml');

class convertHtml_toPdf_openOffice extends convertHtml {
function getDescription() {
return 'convertir du html en pdf';
}

function getFunctionalityCallableMethods() {
return array(
'process'
);
}

function process($html) {

}
}

</pre>

=== Utiliser une fonctionnalité ===

La fonction du noyau bab_functionality::get('convertHtml/toPdf/openOffice'); effectuera une inclusion du fichier "convertHtml/toPdf/openOffice/link.inc" ensuite l'objet convertHtml_toPdf_openOffice sera instancié.

Les niveaux supérieurs de l'arborescence seront complétés avec une copie du fichier link.inc si aucun fichier de lien n'est présent.

Un formulaire sera disponible pour d'administrateur afin de changer les fichiers interfaces des niveaux supérieurs pour redéfinir les fonctions par défaut dans le cas de sous-répertoires multiples.

Pour simplifier l'exécution des fonctions d'interface, le contexte du module ne sera pas recréé avant que la fonction soit appelée. Par conséquent, les variables globales de l'environnement du module ne devront pas être utilisées.

==== Fonctions ====

bab_functionality::getFunctionalities($path) : obtenir les sous-répertoires d'une fonctionnalité

bab_functionality::get($path) : obtenir l'instance de l'objet

bab_functionality::includefile($path) : inclure le fichier de la fonctionnalité afin d'effectuer un héritage

Communication entre les modules

2008-01-08T15:01:03Z

Patricia : /* Utiliser une fonctionnalité */

== Dépendances entre les modules au moment de l'installation ==

Lors de l'installation d'un module, des dépendances peuvent êtres utilisées, le nom des modules dépendants doivent être ajoutés dans le fichier addonini.php avec le numéro de version minimum nécessaire dans la section "addons" :

exemple avec le module ivdashboard qui nécessite le module client :
<pre>

[general]
name="ivdashboard"
version=6.09
description="Gestion de projets INVIVO"
db_prefix="ivd_"
ov_version=5.6.2
php_version=4.1.2
mysql_version=3.23

[addons]
clients=2.8

</pre>

== Gestionnaire d'événements et fonctionnalités ==

Pour que les différents modules puissent partager des fonctions, les développeurs pourront utiliser le [[API du gestionnaire d'événement|gestionnaire d'événements]]

[[Image:Com addons.svg]]

== API des fonctionalités ==

'''Attention, cette API sera disponible à partir de ovidentia 6.6.0'''

=== Proposer des fonctionnalités ===

Chaque fonctionnalité devra être nommée selon un "chemin", par exemple "convertHtml/toPdf/openOffice", les caractères _ sont interdis dans le chemin.

Une fonction du noyau d'ovidentia permettra d'enregistrer un fichier php en tant que fonctionnalité, le fichier devra contenir une classe PHP nommée en utilisant la même arborescence, par exemple :

<pre>
class convertHtml_toPdf_openOffice extends bab_functionality {

}

</pre>

le _ remplace le / dans le nom de la classe
l'objet devra être hérité de bab_functionality.

Au moment de l'installation ou du programme de reprise, il faut enregistrer la fonctionnalité dans ovidentia, exemple :

<pre>
include_once $GLOBALS['babInstallPath'].'utilit/functionalityincl.php';

$func = new bab_functionalities();
$func->register("convertHtml/toPdf/openOffice", $GLOBALS['babAddonUrl'].'convert.php');
</pre>

Dans Ovidentia, un fichier "link.inc" sera créé dans un arbre de répertoire avec pour contenu du code php pour inclure le fichier passé en 2ème paramètre.

==== Héritage de fonctionnalités ====

Il est possible de créer une fonctionnalité qui hérite et utilise l'interface d'une autre fonctionnalité.

exemple : le module "convert" propose une fonctionnalité pour convertir du html

<pre>

class convertHtml extends bab_functionality {
function getDescription() {
return 'convertir du html vers un autre format';
}

function getFunctionalityCallableMethods() {
return array(
'process'
);
}

function process($html) {
return NULL;
}
}

</pre>

Dans un autre module "convertToPdf", on propose de convertir du html en pdf en utilisant openOffice. Pour que la fonctionnalité soit acceptée par le programme d'installation, l'objet doit contenir au moins les méthodes du parent. La liste des méthodes sera comparée en utilisant "getFunctionalityCallableMethods".

<pre>

bab_functionality::includefile('convertHtml');

class convertHtml_toPdf_openOffice extends convertHtml {
function getDescription() {
return 'convertir du html en pdf';
}

function getFunctionalityCallableMethods() {
return array(
'process'
);
}

function process($html) {

}
}

</pre>

=== Utiliser une fonctionnalité ===

La fonction du noyau bab_functionality::get('convertHtml/toPdf/openOffice'); effectuera une inclusion du fichier "convertHtml/toPdf/openOffice/link.inc" ensuite l'objet convertHtml_toPdf_openOffice sera instancié.

Les niveaux supérieurs de l'arborescence seront complétés avec une copie du fichier link.inc si aucun fichier de lien n'est présent.

Un formulaire sera disponible pour d'administrateur afin de changer les fichiers interfaces des niveaux supérieurs pour redéfinir les fonctions par défaut dans le cas de sous-répertoires multiples.

Pour simplifier l'exécution des fonctions d'interface, le contexte du module ne sera pas recréé avant que la fonction soit appelée. Par conséquent, les variables globales de l'environnement du module ne devront pas être utilisées.

==== Fonctions ====

bab_functionality::getFunctionalities($path) : obtenir les sous répertoires d'une fonctionnalité

bab_functionality::get($path) : obtenir l'instance de l'objet

bab_functionality::includefile($path) : inclure le fichier de la fonctionnalité afin d'effectuer un héritage

Communication entre les modules

2008-01-08T14:58:31Z

Patricia : /* Proposer des fonctionnalités */

== Dépendances entre les modules au moment de l'installation ==

Lors de l'installation d'un module, des dépendances peuvent êtres utilisées, le nom des modules dépendants doivent être ajoutés dans le fichier addonini.php avec le numéro de version minimum nécessaire dans la section "addons" :

exemple avec le module ivdashboard qui nécessite le module client :
<pre>

[general]
name="ivdashboard"
version=6.09
description="Gestion de projets INVIVO"
db_prefix="ivd_"
ov_version=5.6.2
php_version=4.1.2
mysql_version=3.23

[addons]
clients=2.8

</pre>

== Gestionnaire d'événements et fonctionnalités ==

Pour que les différents modules puissent partager des fonctions, les développeurs pourront utiliser le [[API du gestionnaire d'événement|gestionnaire d'événements]]

[[Image:Com addons.svg]]

== API des fonctionalités ==

'''Attention, cette API sera disponible à partir de ovidentia 6.6.0'''

=== Proposer des fonctionnalités ===

Chaque fonctionnalité devra être nommée selon un "chemin", par exemple "convertHtml/toPdf/openOffice", les caractères _ sont interdis dans le chemin.

Une fonction du noyau d'ovidentia permettra d'enregistrer un fichier php en tant que fonctionnalité, le fichier devra contenir une classe PHP nommée en utilisant la même arborescence, par exemple :

<pre>
class convertHtml_toPdf_openOffice extends bab_functionality {

}

</pre>

le _ remplace le / dans le nom de la classe
l'objet devra être hérité de bab_functionality.

Au moment de l'installation ou du programme de reprise, il faut enregistrer la fonctionnalité dans ovidentia, exemple :

<pre>
include_once $GLOBALS['babInstallPath'].'utilit/functionalityincl.php';

$func = new bab_functionalities();
$func->register("convertHtml/toPdf/openOffice", $GLOBALS['babAddonUrl'].'convert.php');
</pre>

Dans Ovidentia, un fichier "link.inc" sera créé dans un arbre de répertoire avec pour contenu du code php pour inclure le fichier passé en 2ème paramètre.

==== Héritage de fonctionnalités ====

Il est possible de créer une fonctionnalité qui hérite et utilise l'interface d'une autre fonctionnalité.

exemple : le module "convert" propose une fonctionnalité pour convertir du html

<pre>

class convertHtml extends bab_functionality {
function getDescription() {
return 'convertir du html vers un autre format';
}

function getFunctionalityCallableMethods() {
return array(
'process'
);
}

function process($html) {
return NULL;
}
}

</pre>

Dans un autre module "convertToPdf", on propose de convertir du html en pdf en utilisant openOffice. Pour que la fonctionnalité soit acceptée par le programme d'installation, l'objet doit contenir au moins les méthodes du parent. La liste des méthodes sera comparée en utilisant "getFunctionalityCallableMethods".

<pre>

bab_functionality::includefile('convertHtml');

class convertHtml_toPdf_openOffice extends convertHtml {
function getDescription() {
return 'convertir du html en pdf';
}

function getFunctionalityCallableMethods() {
return array(
'process'
);
}

function process($html) {

}
}

</pre>

=== Utiliser une fonctionnalité ===

La fonction du noyau bab_functionality::get('convertHtml/toPdf/openOffice'); effectuera une inclusion du fichier "convertHtml/toPdf/openOffice/link.inc" ensuite l'objet convertHtml_toPdf_openOffice sera instancié.

Les niveaux supérieurs de l'arborescence serons complété avec une copie du fichier link.inc si aucun fichier de lien n'est présent.

Un formulaire sera disponible pour d'administrateur afin de changer les fichiers interface des niveau supérieurs pour redéfinir les fonctions par défaut dans le cas de sous répertoires multiples.

Pour simplifier l'exécution des fonctions d'interface, le contexte du module ne sera pas recréé avant que la fonction soit appelée, par conséquent, l'utilisation des variables globales de l'environnement du module ne devrons pas être utilisées.

==== Fonctions ====

bab_functionality::getFunctionalities($path) : obtenir les sous répertoires d'une fonctionnalité

bab_functionality::get($path) : obtenir l'instance de l'objet

bab_functionality::includefile($path) : inclure le fichier de la fonctionnalité afin d'effectuer un héritage

Communication entre les modules

2008-01-08T14:55:52Z

Patricia : /* Gestionnaire d'événements et fonctionnalités */

== Dépendances entre les modules au moment de l'installation ==

Lors de l'installation d'un module, des dépendances peuvent êtres utilisées, le nom des modules dépendants doivent être ajoutés dans le fichier addonini.php avec le numéro de version minimum nécessaire dans la section "addons" :

exemple avec le module ivdashboard qui nécessite le module client :
<pre>

[general]
name="ivdashboard"
version=6.09
description="Gestion de projets INVIVO"
db_prefix="ivd_"
ov_version=5.6.2
php_version=4.1.2
mysql_version=3.23

[addons]
clients=2.8

</pre>

== Gestionnaire d'événements et fonctionnalités ==

Pour que les différents modules puissent partager des fonctions, les développeurs pourront utiliser le [[API du gestionnaire d'événement|gestionnaire d'événements]]

[[Image:Com addons.svg]]

== API des fonctionalités ==

'''Attention, cette API sera disponible à partir de ovidentia 6.6.0'''

=== Proposer des fonctionnalités ===

chaque fonctionnalité devra être nommée selon un "chemin", par exemple "convertHtml/toPdf/openOffice", les caractères _ sont interdis dans le chemin

une fonction du noyau d'ovidentia permettra d'enregistrer un fichier php en tant que fonctionnalité, le fichier devra contenir une classe PHP nommée en utilisant la même arborescence, par exemple :

<pre>
class convertHtml_toPdf_openOffice extends bab_functionality {

}

</pre>

le _ remplace le / dans le nom de la classe
l'objet devra être hérité de bab_functionality.

au moment de l'installation ou du programme de reprise, il faut enregistrer la fonctionnalité dans ovidentia, exemple :

<pre>
include_once $GLOBALS['babInstallPath'].'utilit/functionalityincl.php';

$func = new bab_functionalities();
$func->register("convertHtml/toPdf/openOffice", $GLOBALS['babAddonUrl'].'convert.php');
</pre>

Dans Ovidentia, un fichier "link.inc" sera créer dans un arbre de répertoire avec pour contenu du code php pour inclure le fichier passé en 2ème paramètre.

==== Héritage de fonctionnalités ====

Il est possible de créer un fonctionnalité qui hérite et utilise l'interface d'une autre fonctionnalité

exemple : le module "convert" propose une fonctionnalité pour convertir du html

<pre>

class convertHtml extends bab_functionality {
function getDescription() {
return 'convertir du html vers un autre format';
}

function getFunctionalityCallableMethods() {
return array(
'process'
);
}

function process($html) {
return NULL;
}
}

</pre>

Dans un autre module "convertToPdf", on propose de convertir du html en pdf en utilisant openOffice, pour que la fonctionnalité soit acceptée par le programme d'installation, l'objet doit contenir au moins les méthodes du parent, la liste des méthode sera comparée en utilisant "getFunctionalityCallableMethods".

<pre>

bab_functionality::includefile('convertHtml');

class convertHtml_toPdf_openOffice extends convertHtml {
function getDescription() {
return 'convertir du html en pdf';
}

function getFunctionalityCallableMethods() {
return array(
'process'
);
}

function process($html) {

}
}

</pre>

=== Utiliser une fonctionnalité ===

La fonction du noyau bab_functionality::get('convertHtml/toPdf/openOffice'); effectuera une inclusion du fichier "convertHtml/toPdf/openOffice/link.inc" ensuite l'objet convertHtml_toPdf_openOffice sera instancié.

Les niveaux supérieurs de l'arborescence serons complété avec une copie du fichier link.inc si aucun fichier de lien n'est présent.

Un formulaire sera disponible pour d'administrateur afin de changer les fichiers interface des niveau supérieurs pour redéfinir les fonctions par défaut dans le cas de sous répertoires multiples.

Pour simplifier l'exécution des fonctions d'interface, le contexte du module ne sera pas recréé avant que la fonction soit appelée, par conséquent, l'utilisation des variables globales de l'environnement du module ne devrons pas être utilisées.

==== Fonctions ====

bab_functionality::getFunctionalities($path) : obtenir les sous répertoires d'une fonctionnalité

bab_functionality::get($path) : obtenir l'instance de l'objet

bab_functionality::includefile($path) : inclure le fichier de la fonctionnalité afin d'effectuer un héritage

Plugins OpenSearch

2008-01-08T14:54:24Z

Patricia : /* Fichier de description OpenSearch */

Les dernières générations de navigateurs (Firefox 2 et Internet Explorer 7) disposent d'une barre de recherche intégrée qui permet à l'utilisateur d'accéder rapidement à un certain nombre de moteurs de recherche (Google, Yahoo, Wikipedia...) La liste des moteurs proposée par ces navigateurs n'est pas figée et il est possible pour l'utilisateur d'en ajouter de nouveaux.
[[Image:searchbar-firefox.jpg|frame|Zone de recherche dans Firefox]]
Pour être intégrable, un moteur de recherche doit être compatible avec certains standards. [http://opensearch.org/ OpenSearch] définit, entre autres, un format de description de moteur de recherche permettant aux navigateurs d'obtenir les informations nécessaires à leur intégration dans la barre de recherche.

Il est possible de définir un plugin pour accéder au moteur d'Ovidentia.

==Fichier de description OpenSearch==

Afin de permettre au navigateur de savoir comment dialoguer avec notre moteur de recherche, il est nécessaire de lui fournir une description de celui-ci.
OpenSearch définit un fichier de description au format XML contenant toutes les informations nécessaires.

Pour Ovidentia, nous nous servirons de l'OvML pour générer le fichier XML. OvML nous permettra d'insérer des éléments dépendants de l'installation d'Ovidentia sur le site (url de base, nom du skin...) et nous n'aurons donc pas besoin de modifier le fichier en cas de changement de paramétrage du site.

Le fichier OvML, que nous appellerons par exemple '''ovisearch.xml''' sera placé dans le répertoire ovml du ''skin'' (skins/''nom_du_skin''/ovml). Son contenu sera le suivant :

<OpenSearchDescription xmlns="http://a9.com/-/spec/opensearch/1.1/"
xmlns:moz="http://www.mozilla.org/2006/browser/search/">
'''<OFPutVar name="babSkinPath"><OFPutVar name="babUrl">'''
<ShortName>Ovidentia</ShortName>
<Description>Recherche Ovidentia</Description>
<InputEncoding>ISO-8859-15</InputEncoding>
<Image width="16" height="16" type="image/vnd.microsoft.icon">
'''<OVbabSkinPath>'''images/Puces/favicon.ico
</Image>
<Url type="text/html"
method="get"
template="'''<OVbabUrl>'''index.php?tg=search&pat=abcdefgh&idx=find&what={searchTerms}">
</Url>
<moz:SearchForm>'''<OVbabUrl>'''index.php?tg=search&pat=abcdefgh</moz:SearchForm>
</OpenSearchDescription>
Les spécifications détaillées (en anglais) du format de fichier de description sont accessibles à cette page : [http://www.opensearch.org/Specifications/OpenSearch/1.1#OpenSearch_description_document OpenSearch description document]

==Découverte automatique du moteur==

Une fois le fichier de description en place, il est possible d'indiquer au navigateur que notre site dispose d'un moteur de recherche compatible avec le standard OpenSearch. Le navigateur avertira ainsi l'utilisateur qu'un moteur de recherche est disponible sur le site et lui permettra de l'ajouter automatiquement à la liste de sa barre de recherche.
Pour cela, il suffit d'ajouter dans la section <head> du template page.html du skin la ligne suivante :

<link rel="search"
type="application/opensearchdescription+xml"
title="Recherche Ovidentia"
href="'''{ babUrl }'''index.php?tg=oml&file='''ovisearch.xml'''&echo=1">

==Références==
<ul>
<li>[http://opensearch.org/ Documentation OpenSearch] (en anglais)</li>
<li>[http://developer.mozilla.org/en/docs/Creating_OpenSearch_plugins_for_Firefox Documentation sur le Mozilla Developer Center] (en anglais)</li>
</ul>

Eclipse

2008-01-08T14:38:16Z

Patricia : /* Récupération du noyau d'Ovidentia */

==Installation d'Eclipse PDT==
La version [http://www.eclipse.org/pdt/ PDT] (PHP Development Tools) d'Eclipse contient la plupart des outils nécessaires au développement d'applications PHP et en particulier d'Ovidentia.

Cette version d'Eclipse est disponible sur la [http://download.eclipse.org/tools/pdt/downloads/ page de téléchargement du projet PDT] :
* choisir le lien de la dernière version ''Release Build'',
* télécharger la version ''all-in-one'' pour la plateforme voulue (unix, windows ou macosx),
* décompresser l'archive,
* lancer le fichier exécutable eclipse dans le répertoire qui vient d'être créé.

==Récupération du noyau d'Ovidentia==
Nous allons créer un projet ovidentia qui contiendra la dernière version CVS du noyau d'Ovidentia.

1. Dans le menu, sélectionner '''File > New > Project...'''

2. Dans la liste, sélectionner '''CVS > Projects from CVS'''

puis '''Next >'''

[[Image:EclipsePDT New Project CVS.jpg|center|border|400px]]
 

3. Sélectionner '''Create a new repository location'''

puis '''Next >'''

Cette étape va nous permettre de définir l'accès au dépôt CVS d'Ovidentia. Cette configuration pourra être utilisée par la suite pour d'autres projets.

[[Image:EclipsePDT Checkout from CVS.jpg|center|border|400px]]
 

4. Saisir les informations concernant le dépôt CVS : 
''Host'': '''cvs.ovidentia.org''' 
''Repository path'': '''/home/src/public''' 
''User'': '''anonymous''' 
''Password'': 
''Connection type'': '''pserver''' et '''Use default port''' 

puis '''Next >'''

Nous configurons ici un simple accès anonyme à CVS qui nous permettra d'accéder au noyau et aux modules publics. Un accès anonyme ne donne cependant pas la possibilité de faire de ''commit''.
Si vous disposez d'un compte sur le serveur CVS, il faut utiliser les paramètres suivants :

''Host'': '''cvs.ovidentia.org''' 
''Repository path'': '''/home/src/public''' 
''User'': '''mon_login''' 
''Password'': 
''Connection type'': '''extssh''' et '''Use default port''' 

[[Image:EclipsePDT Checkout from CVS 1.jpg|center|border|400px]]
 

5. Sélectionner '''Check out as project configured using the New Project Wizard'''

puis '''Next >'''

Cette étape va nous permettre de définir le type de projet que nous créons (projet PHP).

[[Image:EclipsePDT Check Out As.jpg|center|border|400px]]
 

6. Sélectionner '''HEAD''' dans la liste

puis '''Finish'''

HEAD est la branche en cours de développement du noyau.

[[Image:EclipsePDT Check Out As 1.jpg|center|border|400px]]
 

7. Sélectionner '''PHP Project''' dans la liste

puis '''Next >'''

Cette étape permet de spécifier à Eclipse que le projet est un projet PHP. Tous les outils seront donc configurés en conséquence lorsque l'on travaillera sur ce projet.

[[Image:EclipsePDT New Project PHP.jpg|center|border|400px]]
 

8. Saisir le nom du projet dans la case '''Project Name''', par exemple '''ovidentia_head'''.

puis '''Finish'''

[[Image:EclipsePDT PHP Project .jpg|center|border|400px]]

Indexation

2008-01-08T14:33:10Z

Patricia : /* Indexation planifiée */

== Utiliser l'indexation dans un module ==

...

== Indexation planifiée ==

Rajouter &prepare=1 dans les url d'indexation.

Le script génère un fichier .bat pour l'execution.

Les appels du système vers ovidentia se font par défaut au travers de wget, il est possible de modifier l'outil utilisé, exemple avec curl, ligne à ajouter dans config.php :

define('BAB_SWISHE_WGET_URL', 'curl %s > /dev/null 2>&1');

API Addon - OVML

2008-01-08T14:31:45Z

Patricia : /* Utilisation */

== Introduction ==
L'API addon-OvML permet à un addon d'accéder à tous les containers OVML.
Il est ainsi possible à un addon de lister les catégories, les thèmes d'articles, les articles,
les contributions d'un forum etc ...

Tous les fonctionnalités offertes par l'OVML sont ainsi disponibles à un addon.

== Utilisation ==
Afin d'utiliser cette API, l'addon doit inclure le fichier '''''ovmlapi.php''''':

<pre>
include_once $babInstallPath.'utilit/ovmlapi.php';
</pre>

L'interraction de l'addon avec cette API se fait par l'intermédiaire de la classe '''''bab_ovmlAPI''''':

<pre>
include_once $babInstallPath.'utilit/ovmlapi.php';

function list_topics()
{
global $babBody;

class list_topics_class
{
function list_topics_class()
{
$this->tpl = new bab_ovmlAPI();
}
}
...

}

</pre>

L'instanciation de cette classe créée un context global pour l'OVML.
Il est possible de passer des variables à ce context en utilisant le paramètre '''''$args''''':

<pre>
include_once $babInstallPath.'utilit/ovmlapi.php';

function list_topics()
{
global $babBody;

class list_topics_class
{
function list_topics_class()
{
$args['babHtmlEntities'] = 1;
$args['topics'] = bab_gp('topicid');
$this->tpl = new bab_ovmlAPI($args);
}
}
...
}

</pre>

L'instantiation d'un container OVML se fait par la méthode '''''getContainer''''':

<pre>
include_once $babInstallPath.'utilit/ovmlapi.php';

function list_topics()
{
global $babBody;

class list_topics_class
{
function list_topics_class()
{
$this->tpl = new bab_ovmlAPI();
$args['topicid'] = 12;
$args['archive']='No';
$args['topicorder']='Yes';
$this->cont = $this->tpl->getContainer('ArticleTopics', $args);
}
}
...
}

</pre>

Dans ce qui précède, on instancie le container OCArticleTopics et on lui passe
les paramètres ''topicid'', ''archive'' et ''topicorder''.

On peut ajouter des paramètres au context courant et en récupérer en utilisant les
deux méthodes suivantes :

<pre>
$vars[] = array('name'=>'count', 'value' => $count);
$vars[] = array('name'=>'index', 'value' => 0);
$this->tpl->putVar($vars);
$title = $this->tpl->getVar('ArticleTitle');
$author = $this->tpl->getVar('ArticleAuthor', array('author'=>'%F %L'))
</pre>

La méthode ''''getContainer'''' retourne un objet implémentant la méthode ''''getnext''''
permettant de récupérer les résultats du containers.
La méthode ''''getnext'''' retourne ''false'' quand il n'y a plus de résulat et ''true'' dans le cas
contraire.
Quand la méthode retourne false, elle détruit automatiquement son context.
Sinon, vous avez la possibilité de détruire le context en appelant la méthode :

<pre>

$this->cont = $this->tpl->getContainer('ArticleTopics', $args);
$thsi->cont->destroyContext();
</pre>

L'appel à ''''destroyContext'''' détruit le context courant et supprime les variables.

Normalement, à chaque appel à la methode ''''getnext'''', le système créé les variables du container
dans l'objet implémentant la méthode ''''getnext'''':

<pre>
include_once $babInstallPath.'utilit/ovmlapi.php';

function list_articles()
{
global $babBody;

class list_articles_class
{
function list_articles_class()
{
$this->tpl = new bab_ovmlAPI();
$args['topicid'] = 12;
$args['archive']='No';
$args['topicorder']='Yes';
$this->cont = $this->tpl->getContainer('ArticleTopics', $args);
}

function getnextarticle()
{
if( $this->cont->getnext() )
{
$this->title = $this->cont->ArticleTitle;
return true;
}
else
{
return false;
}
}

}
...
}
</pre>

Si l'on souhaite créer ces variables dans un autre objet, on peut passer cet objet à chaque
appel à la fonction ''''getnext'''':

<pre>
include_once $babInstallPath.'utilit/ovmlapi.php';

function list_articles()
{
global $babBody;

class list_articles_class
{
function list_articles_class()
{
$this->tpl = new bab_ovmlAPI();
$args['topicid'] = 12;
$args['archive']='No';
$args['topicorder']='Yes';
$this->cont = $this->tpl->getContainer('ArticleTopics', $args);
}

function getnextarticle()
{
if( $this->cont->getnext($this) )
{
echo $this->ArticleTitle;
return true;
}
else
{
return false;
}
}

}
...
}
</pre>

API editeur

2008-01-08T14:28:04Z

Patricia : /* API pour créer un module éditeur */

==Fonctions à remplacer==

<pre>
bab_editor($content, $editname, $formname, $heightpx=300, $what=3)
</pre>

cette fonction retourne du html

<pre>
bab_editor_record(&$str)
</pre>

Cette fonction est appelée au moment de la récupération des données soumises par l'éditeur

<pre>
bab_replace_ref(&$str)
</pre>

cette fonction est appelée au moment de l'affichage du texte enregistré par l'éditeur.

==API pour implémenter un éditeur==

syntaxe utilisée dans le nom des fonctions :

* Editor : le html de l'éditeur
* Content : le contenu à stoquer dans la base
* Html : le contenu transformé en html pour l'affichage

Pour le HTML nécessaire à l'éditeur, un objet sera utilisé.
Pour afficher l'éditeur au moment de la modification d'un texte :

<pre>
include_once $GLOBALS['babInstallPath']."utilit/editorincl.php";

$editor = new bab_contentEditor($uid);
$editor->setRequestFieldName('textarea_name');
$editor->setContent($content);
$editor->setParameters(array('height' => 300));
$editor_html = $editor->getEditor();
</pre>

setRequestFieldName est optionnel, il permet de définir le nom du champ posté, si la méthode n'est pas appelée, $uid est utilisé comme nom dans le html

Avant d'enregistrer dans la base :

<pre>
$editor = new bab_contentEditor($uid);
$editor->setRequestFieldName('textarea_name');
$content = $editor->getContent();
$format = $editor->getFormat();
</pre>

Pour afficher du contenu qui a été enregistré avec l'éditeur :

<pre>
$editor = new bab_contentEditor($uid);
$editor->setContent($content);
$html = $editor->getHtml();
</pre>

Pour chaque éditeur, un enregistrement doit être ajouté sur cet événement :
'''bab_eventEditors'''

<pre>
include_once $GLOBALS['babInstallPath']."utilit/eventincl.php";
bab_addEventListener('bab_eventEditors', 'xxx_getEditorDetails', 'xxx.php');
</pre>

Il faut prévoir une fonction qui permet d'identifier l'éditeur :

<pre>
function xxx_getEditorDetails($event) {
$event->addEditor($uid, 'Editor label', 'Editor description');
}
</pre>

Pour les fonctions externes qui insèrent du html dans l'éditeur, chaque fonction doit s'inscrire sur cet événement :

'''bab_eventEditorContentToHtml''' cet événement sera appelé au moment de l'affichage de la popup avec les listes des fonctions qui permettent d'insérer du html dans l'éditeur. S'enregistrer sur cet événement permet d'ajouter des fonctions comme l'insertion d'un fichier du gestionnaire de fichier ou une fiche annuaire.

si $babBody n'est pas utilisé pour l'affichage des pages, il faut inclure manuellement des fichiers :

$babBody->addJavascriptFile($GLOBALS['babInstallPath'].'scripts/bab_dialog.js');
$babBody->addJavascriptFile($GLOBALS['babInstallPath'].'scripts/text_toolbar.js');
$babBody->addStyleSheet('text_toolbar.css');

==API pour créer un module éditeur==

Des événements seront définis pour permettre de fournir un éditeur à partir d'un module :

'''bab_eventEditorContentToEditor''' permet de créer le template HTML de l'éditeur, cet événement sera appelé par $editor->getEditor()

'''bab_eventEditorRequestToContent''' cet événement sera appelé par $editor->getContent()

'''bab_eventEditorContentToHtml''' cet événement sera appelé par $editor->getHtml()

===Création d'un module ovidentia qui propose un éditeur WYSIWYG===

Les modules peuvent fournir un éditeur pour les formulaires de modification du contenu du noyau et des autres modules, il faut obligatoirement traiter les 3 événements de la gestion des éditeurs afin que la gestion du html soit sécurisée.

Il est possible d'effectuer des action spécifiques en fonction du paramètre "uid" de l'éditeur. Cette fonctionnalité est optionnelle.

====pré requis pour qu'un éditeur soit compatible avec ovidentia====

* Ajout d'un bouton personnalisé qui appelle du javascript (ouverture d'une popup ovidentia)
* Possibilité de récupérer le html sélectionné par API au moment du click sur le bouton
* Possibilité d'insérer du html à la place de la sélection par API
* Le code récupéré doit être transformable en XHTML 1.0 transitional
* la hauteur de la textarea doit être paramétrable en pixel

====Gestion des éditeurs====

Lors de l'installation du module, il faut enregistrer les événements de notification pour que le module soit prévenu lors des actions effectuées sur les différentes implémentations de l'éditeur.

<pre>
include_once $GLOBALS['babInstallPath']."utilit/eventincl.php";
bab_addEventListener('bab_eventEditorContentToHtml', 'fcke_contentToHtml', 'addon/fckeditor/events.php', 'fckeditor');
bab_addEventListener('bab_eventEditorRequestToContent', 'fcke_requestToContent', 'addon/fckeditor/events.php', 'fckeditor');
bab_addEventListener('bab_eventEditorContentToHtml', 'fcke_contentToHtml', 'addon/fckeditor/events.php', 'fckeditor');
</pre>

Lors de chaque appel d'une fonction événementielle, un paramètre sera envoyé contenant les informations de l'éditeur ; c'est l'objet bab_editor qui sera inclu dans l'objet de l'événement déclenché. Le module aura accès à ces informations :

événement bab_eventEditorContentToHtml :

* uid : identifiant unique de l'éditeur en chaine de caractère, par exemple : "bab_article_head" pour l'introduction d'un article
* request_field_name : nom du champ html
* height : la hauteur demandée pour la case d'édition en pixel
* content : contenu à modifier

la variable output_editor devra être renseignée lors de cette action

événement bab_eventEditorRequestToContent :

* uid
* request_field_name : nom du champ html

la variable output_content devra être renseignée lors de cette action

événement bab_eventEditorContentToHtml :

* uid
* content : contenu à afficher

La variable output_html devra être renseignée lors de cette action

====Récupérer la liste des instances de l'éditeur====

Partout ou l'éditeur est utilisé, le nom de l'éditeur a été inscrit dans l'événement bab_eventEditors, pour récupérer la liste des éditeurs, il faut créer un objet d'événement :

<pre>

class bab_eventEditors extends bab_event {
function addEditor($uid, $name, $description) {

}
}

$event = new bab_eventEditors();
bab_fireEvent($event);
</pre>

API editeur

2008-01-08T14:25:16Z

Patricia : /* API pour implémenter un éditeur */

==Fonctions à remplacer==

<pre>
bab_editor($content, $editname, $formname, $heightpx=300, $what=3)
</pre>

cette fonction retourne du html

<pre>
bab_editor_record(&$str)
</pre>

Cette fonction est appelée au moment de la récupération des données soumises par l'éditeur

<pre>
bab_replace_ref(&$str)
</pre>

cette fonction est appelée au moment de l'affichage du texte enregistré par l'éditeur.

==API pour implémenter un éditeur==

syntaxe utilisée dans le nom des fonctions :

* Editor : le html de l'éditeur
* Content : le contenu à stoquer dans la base
* Html : le contenu transformé en html pour l'affichage

Pour le HTML nécessaire à l'éditeur, un objet sera utilisé.
Pour afficher l'éditeur au moment de la modification d'un texte :

<pre>
include_once $GLOBALS['babInstallPath']."utilit/editorincl.php";

$editor = new bab_contentEditor($uid);
$editor->setRequestFieldName('textarea_name');
$editor->setContent($content);
$editor->setParameters(array('height' => 300));
$editor_html = $editor->getEditor();
</pre>

setRequestFieldName est optionnel, il permet de définir le nom du champ posté, si la méthode n'est pas appelée, $uid est utilisé comme nom dans le html

Avant d'enregistrer dans la base :

<pre>
$editor = new bab_contentEditor($uid);
$editor->setRequestFieldName('textarea_name');
$content = $editor->getContent();
$format = $editor->getFormat();
</pre>

Pour afficher du contenu qui a été enregistré avec l'éditeur :

<pre>
$editor = new bab_contentEditor($uid);
$editor->setContent($content);
$html = $editor->getHtml();
</pre>

Pour chaque éditeur, un enregistrement doit être ajouté sur cet événement :
'''bab_eventEditors'''

<pre>
include_once $GLOBALS['babInstallPath']."utilit/eventincl.php";
bab_addEventListener('bab_eventEditors', 'xxx_getEditorDetails', 'xxx.php');
</pre>

Il faut prévoir une fonction qui permet d'identifier l'éditeur :

<pre>
function xxx_getEditorDetails($event) {
$event->addEditor($uid, 'Editor label', 'Editor description');
}
</pre>

Pour les fonctions externes qui insèrent du html dans l'éditeur, chaque fonction doit s'inscrire sur cet événement :

'''bab_eventEditorContentToHtml''' cet événement sera appelé au moment de l'affichage de la popup avec les listes des fonctions qui permettent d'insérer du html dans l'éditeur. S'enregistrer sur cet événement permet d'ajouter des fonctions comme l'insertion d'un fichier du gestionnaire de fichier ou une fiche annuaire.

si $babBody n'est pas utilisé pour l'affichage des pages, il faut inclure manuellement des fichiers :

$babBody->addJavascriptFile($GLOBALS['babInstallPath'].'scripts/bab_dialog.js');
$babBody->addJavascriptFile($GLOBALS['babInstallPath'].'scripts/text_toolbar.js');
$babBody->addStyleSheet('text_toolbar.css');

==API pour créer un module éditeur==

Des événements serons définis pour permettre de fournir un éditeur à partir d'un module :

'''bab_eventEditorContentToEditor''' permet de créer le template HTML de l'éditeur, cet événement sera appelé par $editor->getEditor()

'''bab_eventEditorRequestToContent''' cet événement sera appelé par $editor->getContent()

'''bab_eventEditorContentToHtml''' cet événement sera appelé par $editor->getHtml()

===Création d'un module ovidentia qui propose un éditeur WYSIWYG===

Les modules peuvent fournir un éditeur pour les formulaire de modification du contenu du noyau et des autres modules, il faut obligatoirement traiter les 3 événements de la gestion des éditeurs afin que la gestion du html soit sécurisée.

Il est possible d'effectuer des action spécifiques en fonction du paramètre "uid" de l'éditeur. Cette fonctionnalité est optionnelle.

====pré requis pour qu'un éditeur soit compatible avec ovidentia====

* Ajout d'un bouton personnalisé qui appelle du javascript (ouverture d'une popup ovidentia)
* Possibilité de récupérer le html sélectionné par API au moment du click sur le bouton
* Possibilité d'insérer du html à la place de la sélection par API
* Le code récupéré doit être transformable en XHTML 1.0 transitional
* la hauteur de la textarea doit être paramétrable en pixel

====Gestion des éditeur====

lors de l'installation du module, il faut enregistrer les événements de notification pour que le module soit prévenu lors des actions effectuées sur les différentes implémentations de l'éditeur.

<pre>
include_once $GLOBALS['babInstallPath']."utilit/eventincl.php";
bab_addEventListener('bab_eventEditorContentToHtml', 'fcke_contentToHtml', 'addon/fckeditor/events.php', 'fckeditor');
bab_addEventListener('bab_eventEditorRequestToContent', 'fcke_requestToContent', 'addon/fckeditor/events.php', 'fckeditor');
bab_addEventListener('bab_eventEditorContentToHtml', 'fcke_contentToHtml', 'addon/fckeditor/events.php', 'fckeditor');
</pre>

Lors de chaque appel d'une fonction événementielle, un paramètre sera envoyé contenant les information de l'éditeur, c'est l'objet bab_editor qui sera inclu dans l'objet de l'événement déclenché. Le module aura accès à ces informations :

événement bab_eventEditorContentToHtml :

* uid : identifiant unique de l'éditeur en chaine de caractère, par exemple : "bab_article_head" pour l'introduction d'un article
* request_field_name : nom du champ html
* height : la hauteur demandée pour la case d'édition en pixel
* content : contenu à modifier

la variable output_editor devra être renseignée lors de cette action

événement bab_eventEditorRequestToContent :

* uid
* request_field_name : nom du champ html

la variable output_content devra être renseignée lors de cette action

événement bab_eventEditorContentToHtml :

* uid
* content : contenu à afficher

La variable output_html devra être renseignée lors de cette action

====Récupérer la liste des instances de l'éditeur====

Partout ou l'éditeur est utilisé, le nom de l'éditeur à été inscrit dans l'événement bab_eventEditors, pour récupérer la liste des éditeurs, il faut créer un object d'événement :

<pre>

class bab_eventEditors extends bab_event {
function addEditor($uid, $name, $description) {

}
}

$event = new bab_eventEditors();
bab_fireEvent($event);
</pre>

API editeur

2008-01-08T14:24:49Z

Patricia : /* API pour implémenter un éditeur */

==Fonctions à remplacer==

<pre>
bab_editor($content, $editname, $formname, $heightpx=300, $what=3)
</pre>

cette fonction retourne du html

<pre>
bab_editor_record(&$str)
</pre>

Cette fonction est appelée au moment de la récupération des données soumises par l'éditeur

<pre>
bab_replace_ref(&$str)
</pre>

cette fonction est appelée au moment de l'affichage du texte enregistré par l'éditeur.

==API pour implémenter un éditeur==

syntaxe utilisée dans le nom des fonctions :

* Editor : le html de l'éditeur
* Content : le contenu à stoquer dans la base
* Html : le contenu transformé en html pour l'affichage

Pour le HTML nécessaire à l'éditeur, un objet sera utilisé,
Pour afficher l'éditeur au moment de la modification d'un texte :

<pre>
include_once $GLOBALS['babInstallPath']."utilit/editorincl.php";

$editor = new bab_contentEditor($uid);
$editor->setRequestFieldName('textarea_name');
$editor->setContent($content);
$editor->setParameters(array('height' => 300));
$editor_html = $editor->getEditor();
</pre>

setRequestFieldName est optionnel, il permet de définir le nom du champ posté, si la méthode n'est pas appelée, $uid est utilisé comme nom dans le html

Avant d'enregistrer dans la base :

<pre>
$editor = new bab_contentEditor($uid);
$editor->setRequestFieldName('textarea_name');
$content = $editor->getContent();
$format = $editor->getFormat();
</pre>

Pour afficher du contenu qui a été enregistré avec l'éditeur :

<pre>
$editor = new bab_contentEditor($uid);
$editor->setContent($content);
$html = $editor->getHtml();
</pre>

Pour chaque éditeur, un enregistrement doit être ajouté sur cet événement :
'''bab_eventEditors'''

<pre>
include_once $GLOBALS['babInstallPath']."utilit/eventincl.php";
bab_addEventListener('bab_eventEditors', 'xxx_getEditorDetails', 'xxx.php');
</pre>

Il faut prévoir une fonction qui permet d'identifier l'éditeur :

<pre>
function xxx_getEditorDetails($event) {
$event->addEditor($uid, 'Editor label', 'Editor description');
}
</pre>

Pour les fonctions externes qui insèrent du html dans l'éditeur, chaque fonction doit s'inscrire sur cet événement :

'''bab_eventEditorContentToHtml''' cet événement sera appelé au moment de l'affichage de la popup avec les listes des fonctions qui permettent d'insérer du html dans l'éditeur. S'enregistrer sur cet événement permet d'ajouter des fonctions comme l'insertion d'un fichier du gestionnaire de fichier ou une fiche annuaire.

si $babBody n'est pas utilisé pour l'affichage des pages, il faut inclure manuellement des fichiers :

$babBody->addJavascriptFile($GLOBALS['babInstallPath'].'scripts/bab_dialog.js');
$babBody->addJavascriptFile($GLOBALS['babInstallPath'].'scripts/text_toolbar.js');
$babBody->addStyleSheet('text_toolbar.css');

==API pour créer un module éditeur==

Des événements serons définis pour permettre de fournir un éditeur à partir d'un module :

'''bab_eventEditorContentToEditor''' permet de créer le template HTML de l'éditeur, cet événement sera appelé par $editor->getEditor()

'''bab_eventEditorRequestToContent''' cet événement sera appelé par $editor->getContent()

'''bab_eventEditorContentToHtml''' cet événement sera appelé par $editor->getHtml()

===Création d'un module ovidentia qui propose un éditeur WYSIWYG===

Les modules peuvent fournir un éditeur pour les formulaire de modification du contenu du noyau et des autres modules, il faut obligatoirement traiter les 3 événements de la gestion des éditeurs afin que la gestion du html soit sécurisée.

Il est possible d'effectuer des action spécifiques en fonction du paramètre "uid" de l'éditeur. Cette fonctionnalité est optionnelle.

====pré requis pour qu'un éditeur soit compatible avec ovidentia====

* Ajout d'un bouton personnalisé qui appelle du javascript (ouverture d'une popup ovidentia)
* Possibilité de récupérer le html sélectionné par API au moment du click sur le bouton
* Possibilité d'insérer du html à la place de la sélection par API
* Le code récupéré doit être transformable en XHTML 1.0 transitional
* la hauteur de la textarea doit être paramétrable en pixel

====Gestion des éditeur====

lors de l'installation du module, il faut enregistrer les événements de notification pour que le module soit prévenu lors des actions effectuées sur les différentes implémentations de l'éditeur.

<pre>
include_once $GLOBALS['babInstallPath']."utilit/eventincl.php";
bab_addEventListener('bab_eventEditorContentToHtml', 'fcke_contentToHtml', 'addon/fckeditor/events.php', 'fckeditor');
bab_addEventListener('bab_eventEditorRequestToContent', 'fcke_requestToContent', 'addon/fckeditor/events.php', 'fckeditor');
bab_addEventListener('bab_eventEditorContentToHtml', 'fcke_contentToHtml', 'addon/fckeditor/events.php', 'fckeditor');
</pre>

Lors de chaque appel d'une fonction événementielle, un paramètre sera envoyé contenant les information de l'éditeur, c'est l'objet bab_editor qui sera inclu dans l'objet de l'événement déclenché. Le module aura accès à ces informations :

événement bab_eventEditorContentToHtml :

* uid : identifiant unique de l'éditeur en chaine de caractère, par exemple : "bab_article_head" pour l'introduction d'un article
* request_field_name : nom du champ html
* height : la hauteur demandée pour la case d'édition en pixel
* content : contenu à modifier

la variable output_editor devra être renseignée lors de cette action

événement bab_eventEditorRequestToContent :

* uid
* request_field_name : nom du champ html

la variable output_content devra être renseignée lors de cette action

événement bab_eventEditorContentToHtml :

* uid
* content : contenu à afficher

La variable output_html devra être renseignée lors de cette action

====Récupérer la liste des instances de l'éditeur====

Partout ou l'éditeur est utilisé, le nom de l'éditeur à été inscrit dans l'événement bab_eventEditors, pour récupérer la liste des éditeurs, il faut créer un object d'événement :

<pre>

class bab_eventEditors extends bab_event {
function addEditor($uid, $name, $description) {

}
}

$event = new bab_eventEditors();
bab_fireEvent($event);
</pre>

API du gestionnaire d'événement

2008-01-08T14:20:47Z

Patricia : /* Gestion des priorités */

== table des listener ==

* id
* event_class_name
* function_name
* require_file
* addon_name
* priority

event_class_name est le nom d'une classe héritée de bab_event

function_name est le nom d'une fonction déclarée dans le ficher spécifié dans la colonne require_file

le paramètre require_file est le chemin relatif au noyau d'ovidentia d'un fichier php

le paramètre priority (optionnel) permet de régler l'ordre d'appel des fonctions enregistrés pour un même événement

Ajouter un listener :

<pre>
bab_addEventListener('event_class_name', 'function_name', 'require_file', 'addon_name');
</pre>

Enlever un listener :

<pre>
bab_removeEventListener('event_class_name', 'function_name', 'require_file', 'addon_name');
</pre>

La fonction inscrite dans la colonne function_name sera délarée dans le fichier 'require_file' comme ceci :

<pre>
function ats_onBabPasswordModified(&$event) {

}
</pre>

== Appel d'événement ==

Lors de l'appel d'un événement, toutes les fonctions enregistrées dans la table des "listener" qui ont pour event_class_name le nom de l'objet ou le nom d'un des parents de l'objet sont appelés ; pour chaque enregistrement, on effectue les actions suivantes :

# si 'addon_name' est un nom de module valide, le contexte du module est créé
# le nom du fichier contenu dans 'require_file' est inclu avec la fonction require_once
# la fonction 'function_name' est appelée avec un seul paramètre qui est l'instance de l'événement

<pre>

class bab_userModified extends bab_event {

}

class bab_passwordModified extends bab_userModified {

}

$event_obj = new bab_passwordModified();

bab_fireEvent($event_obj);

</pre>

L'ordre d'appel des fonctions enregistrées dans le listener est indéterminé (le premier enregistré est le premier appelé)

=== Gestion des priorités ===

DRAFT

Lorsque plusieurs fonctions ont été enregistrées sur le même événement, il doit être possible de gérer l'ordre d'appel des différents listeners avec le paramètre 'priority' renseigné lors de l'enregistrement de la fonction

== Tous les événements disponibles ==

=== Ovidentia ===

{|border=1
|Evenement
|Parent
|Description
|-
|bab_eventBeforePeriodsCreated
|bab_event
|Événement appelé au moment de la création d'un planning (agenda, planning de congés...), il est utilisé pour collecter les événements à afficher pour une période donnée
|-
|bab_eventPeriodModified
|bab_event
|Événement appelé lors de la modification d'un ou plusieurs événements sur une période donnée
|-
|bab_eventBeforeWaitingItemsDisplayed
|bab_event
|Événement appelé lors de l'affichage des instances d'approbation en attente sur la page "approbations"
|-
|bab_eventDirectory
|bab_event
|Événement appelé lors d'une intervention sur une fiche d'annuaire ou d'un utilisateur d'ovidentia
|-
|bab_eventDirectoryEntryCreated
|bab_eventDirectory
|Événement appelé lors de la création d'une fiche d'annuaire
|-
|bab_eventDirectoryEntryModified
|bab_eventDirectory
|Événement appelé lors de la modification d'une fiche d'annuaire
|-
|bab_eventDirectoryEntryDeleted
|bab_eventDirectory
|Événement appelé lors de la suppression d'une fiche d'annuaire
|-
|bab_eventUserCreated
|bab_eventDirectory
|Événement appelé lors de la création d'un utilisateur
|-
|bab_eventUserModified
|bab_eventDirectory
|Événement appelé lors de la modification d'un utilisateur
|-
|bab_eventUserDeleted
|bab_eventDirectory
|Événement appelé lors de la suppression d'un utilisateur
|-
|bab_eventGroupDeleted
|bab_event
|Événement appelé lors de la suppression d'un groupe
|-
|bab_eventEditorContentToEditor
|bab_event
|Événement appelé lors de l'affichage d'un éditeur de contenu
|-
|bab_eventEditorRequestToContent
|bab_event
|Événement appelé pour récupérer le contenu enregistré par un éditeur de contenu
|-
|bab_eventEditorContentToHtml
|bab_event
|Événement appelé pour afficher du contenu saisi par un éditeur de contenu
|-
|bab_eventEditors
|bab_event
|Événement appelé pour afficher la liste des implémentations de l'éditeur de contenu
|-
|bab_eventEditorFunctions
|bab_event
|Événement appelé lors de l'affichage de la liste des fonctionnalités d'ovidentia qui peuvent insérer des fragments de html dans un éditeur de contenu
|-
|bab_eventUserAttachedToGroup
|bab_eventDirectory
|Un utilisateur est ajouté dans un groupe
|-
|bab_eventUserDetachedFromGroup
|bab_eventDirectory
|Un utilisateur est enlevé d'un groupe
|}

=== Module ===

API du gestionnaire d'événement

2008-01-08T14:19:35Z

Patricia : /* Appel d'événement */

== table des listener ==

* id
* event_class_name
* function_name
* require_file
* addon_name
* priority

event_class_name est le nom d'une classe héritée de bab_event

function_name est le nom d'une fonction déclarée dans le ficher spécifié dans la colonne require_file

le paramètre require_file est le chemin relatif au noyau d'ovidentia d'un fichier php

le paramètre priority (optionnel) permet de régler l'ordre d'appel des fonctions enregistrés pour un même événement

Ajouter un listener :

<pre>
bab_addEventListener('event_class_name', 'function_name', 'require_file', 'addon_name');
</pre>

Enlever un listener :

<pre>
bab_removeEventListener('event_class_name', 'function_name', 'require_file', 'addon_name');
</pre>

La fonction inscrite dans la colonne function_name sera délarée dans le fichier 'require_file' comme ceci :

<pre>
function ats_onBabPasswordModified(&$event) {

}
</pre>

== Appel d'événement ==

Lors de l'appel d'un événement, toutes les fonctions enregistrées dans la table des "listener" qui ont pour event_class_name le nom de l'objet ou le nom d'un des parents de l'objet sont appelés ; pour chaque enregistrement, on effectue les actions suivantes :

# si 'addon_name' est un nom de module valide, le contexte du module est créé
# le nom du fichier contenu dans 'require_file' est inclu avec la fonction require_once
# la fonction 'function_name' est appelée avec un seul paramètre qui est l'instance de l'événement

<pre>

class bab_userModified extends bab_event {

}

class bab_passwordModified extends bab_userModified {

}

$event_obj = new bab_passwordModified();

bab_fireEvent($event_obj);

</pre>

L'ordre d'appel des fonctions enregistrées dans le listener est indéterminé (le premier enregistré est le premier appelé)

=== Gestion des priorités ===

DRAFT

Lorsque plusieurs fonctions ont été enregistrées sur le même événement, il doit être possible de gérer l'ordre d'appel des différents listeners

avec le paramètre 'priority' renseigné lors de l'enregistrement de la fonction

== Tous les événements disponibles ==

=== Ovidentia ===

{|border=1
|Evenement
|Parent
|Description
|-
|bab_eventBeforePeriodsCreated
|bab_event
|Événement appelé au moment de la création d'un planning (agenda, planning de congés...), il est utilisé pour collecter les événements à afficher pour une période donnée
|-
|bab_eventPeriodModified
|bab_event
|Événement appelé lors de la modification d'un ou plusieurs événements sur une période donnée
|-
|bab_eventBeforeWaitingItemsDisplayed
|bab_event
|Événement appelé lors de l'affichage des instances d'approbation en attente sur la page "approbations"
|-
|bab_eventDirectory
|bab_event
|Événement appelé lors d'une intervention sur une fiche d'annuaire ou d'un utilisateur d'ovidentia
|-
|bab_eventDirectoryEntryCreated
|bab_eventDirectory
|Événement appelé lors de la création d'une fiche d'annuaire
|-
|bab_eventDirectoryEntryModified
|bab_eventDirectory
|Événement appelé lors de la modification d'une fiche d'annuaire
|-
|bab_eventDirectoryEntryDeleted
|bab_eventDirectory
|Événement appelé lors de la suppression d'une fiche d'annuaire
|-
|bab_eventUserCreated
|bab_eventDirectory
|Événement appelé lors de la création d'un utilisateur
|-
|bab_eventUserModified
|bab_eventDirectory
|Événement appelé lors de la modification d'un utilisateur
|-
|bab_eventUserDeleted
|bab_eventDirectory
|Événement appelé lors de la suppression d'un utilisateur
|-
|bab_eventGroupDeleted
|bab_event
|Événement appelé lors de la suppression d'un groupe
|-
|bab_eventEditorContentToEditor
|bab_event
|Événement appelé lors de l'affichage d'un éditeur de contenu
|-
|bab_eventEditorRequestToContent
|bab_event
|Événement appelé pour récupérer le contenu enregistré par un éditeur de contenu
|-
|bab_eventEditorContentToHtml
|bab_event
|Événement appelé pour afficher du contenu saisi par un éditeur de contenu
|-
|bab_eventEditors
|bab_event
|Événement appelé pour afficher la liste des implémentations de l'éditeur de contenu
|-
|bab_eventEditorFunctions
|bab_event
|Événement appelé lors de l'affichage de la liste des fonctionnalités d'ovidentia qui peuvent insérer des fragments de html dans un éditeur de contenu
|-
|bab_eventUserAttachedToGroup
|bab_eventDirectory
|Un utilisateur est ajouté dans un groupe
|-
|bab_eventUserDetachedFromGroup
|bab_eventDirectory
|Un utilisateur est enlevé d'un groupe
|}

=== Module ===

API du gestionnaire de fichiers

2008-01-08T14:17:06Z

Patricia : /* API d'upload */

=== API d'upload ===

Il existe une fonction pour importer des fichiers en masse dans le gestionnaire de fichiers
cf uploadincl.php

<pre>

/**
* Import a file into the file manager
* if the file exists, the file is updated or a new version of the file is created
* @param object $fmFile bab_fmFile instance
* @param int $id_owner
* @param string $path
* @param boolean $bgroup true if the $id_owner is a folder, false if the $id_owner is a user
*
* @return boolean id_file
*/
function bab_importFmFile($fmFile, $id_owner, $path, $bgroup)

</pre>

=== API de download ===

* Il est possible d'utiliser l'api ovml pour obtenir les liens de téléchargement

API de sélection d'utilisateurs

2008-01-08T14:16:12Z

Patricia :

Depuis la version 6.0.2 d'ovidentia 
Voir les javadoc dans le fichier : 'utilit/selectusers.php' 
Voir un exemple d'implémentation dans la rubrique Administration / Congés

<pre>
include_once $GLOBALS['babInstallPath'].'utilit/selectusers.php';
$obj = new bab_selectusers();
</pre>

Ajouter des paramètres de type champs cachés dans le formulaire
<pre>
$obj->addVar('ide', $ide);
</pre>

Ajouter des utilisateurs qui apparaissent dans la liste des utilisateurs sélectionnés
<pre>
$obj->addUser($id);
</pre>

Enregistrer la fonction de callback qui est appelée quand l'utilisateur clique sur enregistrer
<pre>
$obj->setRecordCallback('recordVacationManager');
</pre>

getHtml() pour récupérer le formulaire
<pre>
$GLOBALS['babBody']->babecho($obj->getHtml());
</pre>

Exemple de fonction d'enregistrement

<source lang="php">
function recordVacationManager($userids, $params)
{

$db = $GLOBALS['babDB'];
$db->db_query("DELETE FROM ".BAB_VAC_MANAGERS_TBL."");
foreach($userids as $id) {
$db->db_query("INSERT into ".BAB_VAC_MANAGERS_TBL." (id_user) values (".$db->quote($id).")");
}
}
</source>

Base de registre

2008-01-08T14:13:19Z

Patricia : /* API php */

== Structure de la base de registre ==

La base de registre est un moyen de mémoriser des informations librement dans un arbre sans créer de table et sans utiliser mysql. La facilité d'utilisation est mise en avant au détriment des performances.

disposition des répertoires à la racine :

le répertoire bab/ contient toutes les clefs liées au noyau

un répertoire par module peut être créé

== API php ==

La fonction bab_getRegistryInstance est disponible dans tout ovidentia (fichier addonapi.php), elle permet d'obtenir l'instance de l'objet pour utiliser la base de registre.

exemple :

<pre>
$instance = bab_getRegistryInstance();
</pre>

$instance est un objet bab_registry

=== $instance->changeDirectory($dir) ===

Cette méthode permet de se déplacer dans l'arborescence de la base de registre, $dir est une chaîne de caractères

=== $instance->setKeyValue($key, $value) ===

Méthode utilisée pour créer une clef et une valeur, $key est une chaîne, et $value peut être un objet, un tableau, une chaîne, un nombre entier ou un nombre flottant.

$key ne doit pas contenir de /

=== $instance->removeKey($key) ===

Méthode pour supprimer une clef

=== $instance->getValue($key) ===

Cette méthode permet d'obtenir une valeur enregistrée ou NULLE si la clef n'existe pas, la valeur obtenue sera du même type que celle qui a été enregistrée

=== $instance->getValueEx($key) ===

Cette méthode retourne un tableau avec des informations complémentaires sur la clef

=== $instance->deleteDirectory() ===

Permet d'effacer le répertoire en cours.

== Module regedit ==

le module regedit est en cours de développement (il n'est pas disponible en téléchargement)

Base de registre

2008-01-08T14:10:14Z

Patricia : /* Structure de la base de registre */

== Structure de la base de registre ==

La base de registre est un moyen de mémoriser des informations librement dans un arbre sans créer de table et sans utiliser mysql. La facilité d'utilisation est mise en avant au détriment des performances.

disposition des répertoires à la racine :

le répertoire bab/ contient toutes les clefs liées au noyau

un répertoire par module peut être créé

== API php ==

La fonction bab_getRegistryInstance est disponible dans tout ovidentia (fichier addonapi.php), elle permet d'obtenir l'instance de l'objet pour utiliser la base de registre

exemple :

<pre>
$instance = bab_getRegistryInstance();
</pre>

$instance est un objet bab_registry

=== $instance->changeDirectory($dir) ===

Cette méthode permet de ce déplacer dans l'arborescence de la base de registre, $dir est une chaîne de caractères

=== $instance->setKeyValue($key, $value) ===

Méthode utilisée pour créer une clef et une valeur, $key est une chaine, et $value peut être un objet un tableau une chaîne un nombre entier ou un nombre flottant

$key ne doit pas contenir de /

=== $instance->removeKey($key) ===

Méthode pour supprimer une clef

=== $instance->getValue($key) ===

Cette méthode permet d'obtenir une valeur enregistrée ou NULL si la clef n'existe pas, la valeur obtenue sera du même type que celle qui a été enregistrée

=== $instance->getValueEx($key) ===

Cette méthode retourne un tableau avec des information complémentaires sur la clef

=== $instance->deleteDirectory() ===

Permet d'effacer le répertoire en cours.

== Module regedit ==

le module regedit est en cours de développement (il n'est pas disponible en téléchargement)

API des ACL (Access Control List)

2008-01-08T14:03:58Z

Patricia : /* Gestion des tables de droits */

== Fonction pour enregistrer les droits ==

Pour afficher un formulaire de droits ACL, il faut inclure un fichier php :

<pre>
global $babInstallPath;
include_once $babInstallPath."admin/acl.php";
</pre>

=== L'object macl (multiple access control list) ===

<pre>
$macl = new macl('tg_value', 'idx_value', $id_object, 'returnvar', $bsetofgroups, $iddelegation);
$macl->addtable( 'bab_table_name',bab_translate("Who can manage this environement?"));
$macl->filter(0,0,1,1,1);
$macl->babecho();
</pre>

l'object "macl" permet la création d'un formulaire acl pour un seul object $id_object.
Les paramètres 'tg_value' et 'idx_value' seront enregistrés dans le formulaire comme valeur pour les champs cachés tg et idx. La variable $_POST['returnvar'] sera déclarée lors du retour du formulaire.

Le paramètre $besetofgroups (booléen) permet d'afficher les ensembles de groupes ou non. Par défaut, les ensembles de groupes sont affichés (true).

Le paramètre $iddelegation permet d'indiquer l'id de délégation à utiliser.
Si la valeur est nulle, le système utilise l'id de la délégation courante.

la méthode addtable() permet d'ajouter une ou plusieurs tables de droits. La méthode doit être appelée une ou plusieurs fois. Le premier paramètre est le nom de la table, le deuxième paramètre est le libellé qui sera affiché sur le formulaire.

Voici un exemple de structure pour la table de droits :
<pre>

CREATE TABLE `bdic_env_groups` (
`id` int(11) unsigned NOT NULL auto_increment,
`id_object` int(11) unsigned NOT NULL default '0',
`id_group` int(11) unsigned NOT NULL default '0',
PRIMARY KEY (`id`),
KEY `id_object` (`id_object`),
KEY `id_group` (`id_group`)
);
</pre>

la méthode "filter" permet de désactiver certaines possibilités du formulaire de droit.

Ci-dessous, la liste des paramètres possibles. Tous les paramètres sont optionnels. la valeur 1 permet de désactiver l'élément souhaité et la valeur 0 pour ne rien faire.

# permet de désactiver la liste des groupes
# fonctionnalité dépréciée (sans effet)
# permet de désactiver le groupe "Utilisateurs d'Ovidentia"
# permet de désactiver le groupe "Utilisateurs enregistrés"
# permet de désactiver le groupe "Utilisateurs anonymes"
# permet de désactiver un ou plusieurs groupes spécifiés par leur ID (le paramètre est un tableau)

la méthode "babecho()" permet d'afficher le formulaire.

la méthode "getHtml()" permet de récupérer le html du formulaire.

la méthode "set_hidden_field($sName, $sValue)" permet de définir des champs cachés supplémentaires.

=== Enregistrement du formulaire de droit ===

Pour enregistrer le résultat du formulaire de droit, appeler la fonction : '''maclGroups()'''

=== Enregistrer des droits par API ===

'''aclDuplicateRights($srcTable, $srcIdObject, $trgTable, $trgIdObject)'''

cette fonction permet de copier les droits d'un objet vers un autre objet

'''aclCloneRights($srcTable, $srcIdObject, $trgTable, $trgIdObject)'''

cette fonction permet de cloner un droit d'un objet à partir des droits d'un autre objet

'''aclSetGroups_all($table, $id_object)'''

Pour donner accès à tous les utilisateurs d'ovidentia

'''aclSetGroups_registered($table, $id_object)'''

Pour donner accès aux utilisateurs enregistrés

'''aclSetGroups_unregistered($table, $id_object)'''

Pour donner accès aux utilisateurs anonymes

== Fonctions pour tester les droits ==

Pour vérifier si l'utilisateur connecté a le droit d'accéder ou non à un objet, utiliser la fonction suivante :

===bab_isAccessValid($table_name, $id_object);===

Cette fonction renvoie true ou false selon que l'utilisateur a accès ou non à l'objet testé.

La fonction suivante renvoie la liste des objets auquel l'utilisateur a accès sur une table de droits :

===bab_getUserIdObject($table_name);===

Elle renvoie la liste des objets sous forme d'un tableau.

=== Liste des utilisateurs ayant accès à un droit ===
Afin de récupérer l'ensemble des utilisateurs ayant le droit d'accès à un objet, utiliser la fonction :

<pre>
aclGetAccessUsers($table, $id_object)
</pre>

Pour cela, il faut inclure le fichier php des ACL et l'utiliser comme ceci :

<pre>
include_once $GLOBALS['babInstallPath']."admin/acl.php";
$users = aclGetAccessUsers($table, $id_object);
</pre>

La fonction retourne un tableau contenant les utilisateurs qui disposent du droit passé par les paramètres.
Le format de retour est un tableau structuré comme ceci :

<pre>
array(
id_user => array(
'name' => 'user name',
'email' => 'user email or false'
)
)
</pre>

Cette fonction est principalement utilisée pour les notifications par mail.

== Gestion des tables de droits ==

Pour mettre à jour les tables de droits lors d'une suppression, il faut utiliser les fonctions suivantes :

=== aclDelete($table, $id_object) ===

Fonction à appeler lors de la suppression d'un objet

=== aclDeleteGroup($table, $id_group) ===

Fonction à appeler lors de la suppression d'un groupe

API des ACL (Access Control List)

2008-01-08T14:03:22Z

Patricia : /* Fonctions pour tester les droits */

== Fonction pour enregistrer les droits ==

Pour afficher un formulaire de droits ACL, il faut inclure un fichier php :

<pre>
global $babInstallPath;
include_once $babInstallPath."admin/acl.php";
</pre>

=== L'object macl (multiple access control list) ===

<pre>
$macl = new macl('tg_value', 'idx_value', $id_object, 'returnvar', $bsetofgroups, $iddelegation);
$macl->addtable( 'bab_table_name',bab_translate("Who can manage this environement?"));
$macl->filter(0,0,1,1,1);
$macl->babecho();
</pre>

l'object "macl" permet la création d'un formulaire acl pour un seul object $id_object.
Les paramètres 'tg_value' et 'idx_value' seront enregistrés dans le formulaire comme valeur pour les champs cachés tg et idx. La variable $_POST['returnvar'] sera déclarée lors du retour du formulaire.

Le paramètre $besetofgroups (booléen) permet d'afficher les ensembles de groupes ou non. Par défaut, les ensembles de groupes sont affichés (true).

Le paramètre $iddelegation permet d'indiquer l'id de délégation à utiliser.
Si la valeur est nulle, le système utilise l'id de la délégation courante.

la méthode addtable() permet d'ajouter une ou plusieurs tables de droits. La méthode doit être appelée une ou plusieurs fois. Le premier paramètre est le nom de la table, le deuxième paramètre est le libellé qui sera affiché sur le formulaire.

Voici un exemple de structure pour la table de droits :
<pre>

CREATE TABLE `bdic_env_groups` (
`id` int(11) unsigned NOT NULL auto_increment,
`id_object` int(11) unsigned NOT NULL default '0',
`id_group` int(11) unsigned NOT NULL default '0',
PRIMARY KEY (`id`),
KEY `id_object` (`id_object`),
KEY `id_group` (`id_group`)
);
</pre>

la méthode "filter" permet de désactiver certaines possibilités du formulaire de droit.

Ci-dessous, la liste des paramètres possibles. Tous les paramètres sont optionnels. la valeur 1 permet de désactiver l'élément souhaité et la valeur 0 pour ne rien faire.

# permet de désactiver la liste des groupes
# fonctionnalité dépréciée (sans effet)
# permet de désactiver le groupe "Utilisateurs d'Ovidentia"
# permet de désactiver le groupe "Utilisateurs enregistrés"
# permet de désactiver le groupe "Utilisateurs anonymes"
# permet de désactiver un ou plusieurs groupes spécifiés par leur ID (le paramètre est un tableau)

la méthode "babecho()" permet d'afficher le formulaire.

la méthode "getHtml()" permet de récupérer le html du formulaire.

la méthode "set_hidden_field($sName, $sValue)" permet de définir des champs cachés supplémentaires.

=== Enregistrement du formulaire de droit ===

Pour enregistrer le résultat du formulaire de droit, appeler la fonction : '''maclGroups()'''

=== Enregistrer des droits par API ===

'''aclDuplicateRights($srcTable, $srcIdObject, $trgTable, $trgIdObject)'''

cette fonction permet de copier les droits d'un objet vers un autre objet

'''aclCloneRights($srcTable, $srcIdObject, $trgTable, $trgIdObject)'''

cette fonction permet de cloner un droit d'un objet à partir des droits d'un autre objet

'''aclSetGroups_all($table, $id_object)'''

Pour donner accès à tous les utilisateurs d'ovidentia

'''aclSetGroups_registered($table, $id_object)'''

Pour donner accès aux utilisateurs enregistrés

'''aclSetGroups_unregistered($table, $id_object)'''

Pour donner accès aux utilisateurs anonymes

== Fonctions pour tester les droits ==

Pour vérifier si l'utilisateur connecté a le droit d'accéder ou non à un objet, utiliser la fonction suivante :

===bab_isAccessValid($table_name, $id_object);===

Cette fonction renvoie true ou false selon que l'utilisateur a accès ou non à l'objet testé.

La fonction suivante renvoie la liste des objets auquel l'utilisateur a accès sur une table de droits :

===bab_getUserIdObject($table_name);===

Elle renvoie la liste des objets sous forme d'un tableau.

=== Liste des utilisateurs ayant accès à un droit ===
Afin de récupérer l'ensemble des utilisateurs ayant le droit d'accès à un objet, utiliser la fonction :

<pre>
aclGetAccessUsers($table, $id_object)
</pre>

Pour cela, il faut inclure le fichier php des ACL et l'utiliser comme ceci :

<pre>
include_once $GLOBALS['babInstallPath']."admin/acl.php";
$users = aclGetAccessUsers($table, $id_object);
</pre>

La fonction retourne un tableau contenant les utilisateurs qui disposent du droit passé par les paramètres.
Le format de retour est un tableau structuré comme ceci :

<pre>
array(
id_user => array(
'name' => 'user name',
'email' => 'user email or false'
)
)
</pre>

Cette fonction est principalement utilisée pour les notifications par mail.

== Gestion des tables de droits ==

Pour mettre a jour les tables de droits lors d'une suppression, il faut utiliser les fonctions suivantes :

=== aclDelete($table, $id_object) ===

Fonction à appeler lors de la suppression d'un objet

=== aclDeleteGroup($table, $id_group) ===

Fonction à appeler lors de la suppression d'un groupe

API des ACL (Access Control List)

2008-01-08T14:01:38Z

Patricia : /* Fonction pour enregistrer les droits */

== Fonction pour enregistrer les droits ==

Pour afficher un formulaire de droits ACL, il faut inclure un fichier php :

<pre>
global $babInstallPath;
include_once $babInstallPath."admin/acl.php";
</pre>

=== L'object macl (multiple access control list) ===

<pre>
$macl = new macl('tg_value', 'idx_value', $id_object, 'returnvar', $bsetofgroups, $iddelegation);
$macl->addtable( 'bab_table_name',bab_translate("Who can manage this environement?"));
$macl->filter(0,0,1,1,1);
$macl->babecho();
</pre>

l'object "macl" permet la création d'un formulaire acl pour un seul object $id_object.
Les paramètres 'tg_value' et 'idx_value' seront enregistrés dans le formulaire comme valeur pour les champs cachés tg et idx. La variable $_POST['returnvar'] sera déclarée lors du retour du formulaire.

Le paramètre $besetofgroups (booléen) permet d'afficher les ensembles de groupes ou non. Par défaut, les ensembles de groupes sont affichés (true).

Le paramètre $iddelegation permet d'indiquer l'id de délégation à utiliser.
Si la valeur est nulle, le système utilise l'id de la délégation courante.

la méthode addtable() permet d'ajouter une ou plusieurs tables de droits. La méthode doit être appelée une ou plusieurs fois. Le premier paramètre est le nom de la table, le deuxième paramètre est le libellé qui sera affiché sur le formulaire.

Voici un exemple de structure pour la table de droits :
<pre>

CREATE TABLE `bdic_env_groups` (
`id` int(11) unsigned NOT NULL auto_increment,
`id_object` int(11) unsigned NOT NULL default '0',
`id_group` int(11) unsigned NOT NULL default '0',
PRIMARY KEY (`id`),
KEY `id_object` (`id_object`),
KEY `id_group` (`id_group`)
);
</pre>

la méthode "filter" permet de désactiver certaines possibilités du formulaire de droit.

Ci-dessous, la liste des paramètres possibles. Tous les paramètres sont optionnels. la valeur 1 permet de désactiver l'élément souhaité et la valeur 0 pour ne rien faire.

# permet de désactiver la liste des groupes
# fonctionnalité dépréciée (sans effet)
# permet de désactiver le groupe "Utilisateurs d'Ovidentia"
# permet de désactiver le groupe "Utilisateurs enregistrés"
# permet de désactiver le groupe "Utilisateurs anonymes"
# permet de désactiver un ou plusieurs groupes spécifiés par leur ID (le paramètre est un tableau)

la méthode "babecho()" permet d'afficher le formulaire.

la méthode "getHtml()" permet de récupérer le html du formulaire.

la méthode "set_hidden_field($sName, $sValue)" permet de définir des champs cachés supplémentaires.

=== Enregistrement du formulaire de droit ===

Pour enregistrer le résultat du formulaire de droit, appeler la fonction : '''maclGroups()'''

=== Enregistrer des droits par API ===

'''aclDuplicateRights($srcTable, $srcIdObject, $trgTable, $trgIdObject)'''

cette fonction permet de copier les droits d'un objet vers un autre objet

'''aclCloneRights($srcTable, $srcIdObject, $trgTable, $trgIdObject)'''

cette fonction permet de cloner un droit d'un objet à partir des droits d'un autre objet

'''aclSetGroups_all($table, $id_object)'''

Pour donner accès à tous les utilisateurs d'ovidentia

'''aclSetGroups_registered($table, $id_object)'''

Pour donner accès aux utilisateurs enregistrés

'''aclSetGroups_unregistered($table, $id_object)'''

Pour donner accès aux utilisateurs anonymes

== Fonctions pour tester les droits ==

Pour vérifier si l'utilisateur connecté a le droit d'accéder ou non à un objet, utiliser la fonction suivante:

===bab_isAccessValid($table_name, $id_object);===

Cette fonction renvoie true ou false selon que l'utilisateur a accès ou non à l'objet testé.

La fonction suivante renvoie la liste des objets auquel l'utilisateur à accès sur une table de droit:

===bab_getUserIdObject($table_name);===

Elle renvoie la liste des objets sous forme d'un tableau.

=== Liste des utilisateurs ayant accès à un droit ===
Afin de récupérer l'ensemble des utilisateurs ayant le droit d'accès à un objet, utiliser la fonction:

<pre>
aclGetAccessUsers($table, $id_object)
</pre>

Pour cela, il faut inclure le fichier php des ACL et l'utiliser comme ceci :

<pre>
include_once $GLOBALS['babInstallPath']."admin/acl.php";
$users = aclGetAccessUsers($table, $id_object);
</pre>

La fonction retourne un tableau contenant les utilisateurs qui disposent du droit passé par les paramètres.
Le format de retour est un tableau structuré comme ceci :

<pre>
array(
id_user => array(
'name' => 'user name',
'email' => 'user email or false'
)
)
</pre>

Cette fonction est principalement utilisée pour les notifications par mail.

== Gestion des tables de droits ==

Pour mettre a jour les tables de droits lors d'une suppression, il faut utiliser les fonctions suivantes :

=== aclDelete($table, $id_object) ===

Fonction à appeler lors de la suppression d'un objet

=== aclDeleteGroup($table, $id_group) ===

Fonction à appeler lors de la suppression d'un groupe

API des agendas

2008-01-08T13:55:29Z

Patricia :

Les constantes suivantes peuvent être utilisées :
<pre>
define("BAB_PERIOD_WORKING" , 1);
define("BAB_PERIOD_NONWORKING" , 2);
define("BAB_PERIOD_NWDAY" , 4);
define("BAB_PERIOD_CALEVENT" , 8);
define("BAB_PERIOD_TSKMGR" , 16);
define("BAB_PERIOD_VACATION" , 32);
</pre>

Utiliser l'api pour mélanger les différentes sources d'événements (voir exemple dans utilit/mcalincl.php) :
<pre>
$this->whObj = new bab_userWorkingHours(
BAB_dateTime::fromIsoDateTime($startdate),
BAB_dateTime::fromIsoDateTime($enddate)
);
</pre>
Les 2 paramètres sont des objets date générés par BAB_dateTime (voir la classe utilit/dateTime.php).
C'est la période totale de calcul
<pre>
$this->whObj->addIdUser($GLOBALS['BAB_SESS_USERID']);
</pre>
Pour utiliser les informations d'horaire de travail et des congés, il faut ajouter 1 ou plusieurs id utilisateurs.
Pour chaque ID user ajouté, les périodes correspondantes seront prises en compte
<pre>
$this->whObj->addCalendar($this->idcalendar);
</pre>
Pour utiliser les événements d'agenda, il faut ajouter 1 ou plusieurs id d'agenda.
Pour chaque ID calendar ajouté, les périodes correspondantes seront prises en compte
<pre>
$this->whObj->createPeriods(BAB_PERIOD_NWDAY | BAB_PERIOD_WORKING | BAB_PERIOD_VACATION | BAB_PERIOD_CALEVENT);
</pre>
Cette fonction va chercher les informations dans toutes les tables correspondantes aux types de périodes spécifiées en paramètres

<pre>
$this->whObj->orderBoundaries();
</pre>
Fonction à appeler obligatoirement pour préparer les périodes qui doivent être parcourues
<pre>
$p = $this->whObj->getNextEvent(BAB_PERIOD_NWDAY | BAB_PERIOD_VACATION | BAB_PERIOD_CALEVENT)
</pre>
parcourir les événements ; on peut filtrer sur le type avec le paramètre

<pre>
$events = $this->whObj->getEventsBetween(bab_mktime($startdate), bab_mktime($enddate), BAB_PERIOD_NWDAY | BAB_PERIOD_VACATION | BAB_PERIOD_CALEVENT);
</pre>
récupérer un tableau d'événements, les paramètres de date sont des timestamp pour délimiter la période

<pre>
$freeevents = $whObj->getAvailabilityBetween(bab_mktime($startdate), bab_mktime($enddate), $gap);

</pre>

Trouver les périodes de disponibilité entre 2 dates, $gap permet de définir la durée minimum des périodes à remonter (en secondes)
Pour ces 2 dernières fonctions, il faut que la période de récupération des infos soit incluse dans la période total qui a été utilisée à la création de l'objet

API des agendas

2008-01-08T13:54:43Z

Patricia :

Les constantes suivantes peuvent être utilisées :
<pre>
define("BAB_PERIOD_WORKING" , 1);
define("BAB_PERIOD_NONWORKING" , 2);
define("BAB_PERIOD_NWDAY" , 4);
define("BAB_PERIOD_CALEVENT" , 8);
define("BAB_PERIOD_TSKMGR" , 16);
define("BAB_PERIOD_VACATION" , 32);
</pre>

Utiliser l'api pour mélanger les différentes sources d'événements (voir exemple dans utilit/mcalincl.php) :
<pre>
$this->whObj = new bab_userWorkingHours(
BAB_dateTime::fromIsoDateTime($startdate),
BAB_dateTime::fromIsoDateTime($enddate)
);
</pre>
Les 2 paramètres sont des objets date générés par BAB_dateTime (voir la classe utilit/dateTime.php).
C'est la période totale de calcul
<pre>
$this->whObj->addIdUser($GLOBALS['BAB_SESS_USERID']);
</pre>
Pour utiliser les informations d'horaire de travail et des congés, il faut ajouter 1 ou plusieurs id utilisateurs.
Pour chaque ID user ajouté, les périodes correspondantes seront prises en compte
<pre>
$this->whObj->addCalendar($this->idcalendar);
</pre>
Pour utiliser les événements d'agenda, il faut ajouter 1 ou plusieurs id d'agenda
pour chaque ID calendar ajouté, les périodes correspondantes seront prises en compte
<pre>
$this->whObj->createPeriods(BAB_PERIOD_NWDAY | BAB_PERIOD_WORKING | BAB_PERIOD_VACATION | BAB_PERIOD_CALEVENT);
</pre>
Cette fonction va chercher les informations dans toutes les tables correspondantes aux types de périodes spécifiées en paramètres

<pre>
$this->whObj->orderBoundaries();
</pre>
Fonction à appeler obligatoirement pour préparer les périodes qui doivent être parcourues
<pre>
$p = $this->whObj->getNextEvent(BAB_PERIOD_NWDAY | BAB_PERIOD_VACATION | BAB_PERIOD_CALEVENT)
</pre>
parcourir les événements ; on peut filtrer sur le type avec le paramètre

<pre>
$events = $this->whObj->getEventsBetween(bab_mktime($startdate), bab_mktime($enddate), BAB_PERIOD_NWDAY | BAB_PERIOD_VACATION | BAB_PERIOD_CALEVENT);
</pre>
récupérer un tableau d'événements, les paramètres de date sont des timestamp pour délimiter la période

<pre>
$freeevents = $whObj->getAvailabilityBetween(bab_mktime($startdate), bab_mktime($enddate), $gap);

</pre>

Trouver les périodes de disponibilité entre 2 dates, $gap permet de définir la durée minimum des périodes à remonter (en secondes)
Pour ces 2 dernières fonctions, il faut que la période de récupération des infos soit incluse dans la période total qui a été utilisée à la création de l'objet

API des agendas

2008-01-08T13:53:45Z

Patricia :

Les constantes suivantes peuvent être utilisées :
<pre>
define("BAB_PERIOD_WORKING" , 1);
define("BAB_PERIOD_NONWORKING" , 2);
define("BAB_PERIOD_NWDAY" , 4);
define("BAB_PERIOD_CALEVENT" , 8);
define("BAB_PERIOD_TSKMGR" , 16);
define("BAB_PERIOD_VACATION" , 32);
</pre>

Utiliser l'api pour mélanger les différentes sources d'événements (voir exemple dans utilit/mcalincl.php) :
<pre>
$this->whObj = new bab_userWorkingHours(
BAB_dateTime::fromIsoDateTime($startdate),
BAB_dateTime::fromIsoDateTime($enddate)
);
</pre>
Les 2 paramètres sont des objets date générés par BAB_dateTime (voir la classe utilit/dateTime.php).
C'est la période totale de calcul
<pre>
$this->whObj->addIdUser($GLOBALS['BAB_SESS_USERID']);
</pre>
Pour utiliser les informations d'horaire de travail et des congés, il faut ajouter 1 ou plusieurs id utilisateurs
pour chaque ID user ajouté, les périodes correspondantes seront prises en compte
<pre>
$this->whObj->addCalendar($this->idcalendar);
</pre>
Pour utiliser les événements d'agenda, il faut ajouter 1 ou plusieurs id d'agenda
pour chaque ID calendar ajouté, les périodes correspondantes seront prises en compte
<pre>
$this->whObj->createPeriods(BAB_PERIOD_NWDAY | BAB_PERIOD_WORKING | BAB_PERIOD_VACATION | BAB_PERIOD_CALEVENT);
</pre>
Cette fonction va chercher les informations dans toutes les tables correspondantes aux types de périodes spécifiées en paramètres

<pre>
$this->whObj->orderBoundaries();
</pre>
Fonction à appeler obligatoirement pour préparer les périodes qui doivent être parcourues
<pre>
$p = $this->whObj->getNextEvent(BAB_PERIOD_NWDAY | BAB_PERIOD_VACATION | BAB_PERIOD_CALEVENT)
</pre>
parcourir les événements ; on peut filtrer sur le type avec le paramètre

<pre>
$events = $this->whObj->getEventsBetween(bab_mktime($startdate), bab_mktime($enddate), BAB_PERIOD_NWDAY | BAB_PERIOD_VACATION | BAB_PERIOD_CALEVENT);
</pre>
récupérer un tableau d'événements, les paramètres de date sont des timestamp pour délimiter la période

<pre>
$freeevents = $whObj->getAvailabilityBetween(bab_mktime($startdate), bab_mktime($enddate), $gap);

</pre>

Trouver les périodes de disponibilité entre 2 dates, $gap permet de définir la durée minimum des périodes à remonter (en secondes)
Pour ces 2 dernières fonctions, il faut que la période de récupération des infos soit incluse dans la période total qui a été utilisée à la création de l'objet

API des agendas

2008-01-08T13:53:07Z

Patricia :

Les constantes suivantes peuvent être utilisées :
<pre>
define("BAB_PERIOD_WORKING" , 1);
define("BAB_PERIOD_NONWORKING" , 2);
define("BAB_PERIOD_NWDAY" , 4);
define("BAB_PERIOD_CALEVENT" , 8);
define("BAB_PERIOD_TSKMGR" , 16);
define("BAB_PERIOD_VACATION" , 32);
</pre>

Utiliser l'api pour mélanger les différentes sources d'événements (voir exemple dans utilit/mcalincl.php) :
<pre>
$this->whObj = new bab_userWorkingHours(
BAB_dateTime::fromIsoDateTime($startdate),
BAB_dateTime::fromIsoDateTime($enddate)
);
</pre>
Les 2 paramètres sont des objets date générés par BAB_dateTime (voir la classe utilit/dateTime.php)
C'est la période totale de calcul
<pre>
$this->whObj->addIdUser($GLOBALS['BAB_SESS_USERID']);
</pre>
Pour utiliser les informations d'horaire de travail et des congés, il faut ajouter 1 ou plusieurs id utilisateurs
pour chaque ID user ajouté, les périodes correspondantes seront prises en compte
<pre>
$this->whObj->addCalendar($this->idcalendar);
</pre>
Pour utiliser les événements d'agenda, il faut ajouter 1 ou plusieurs id d'agenda
pour chaque ID calendar ajouté, les périodes correspondantes seront prises en compte
<pre>
$this->whObj->createPeriods(BAB_PERIOD_NWDAY | BAB_PERIOD_WORKING | BAB_PERIOD_VACATION | BAB_PERIOD_CALEVENT);
</pre>
Cette fonction va chercher les informations dans toutes les tables correspondantes aux types de périodes spécifiées en paramètres

<pre>
$this->whObj->orderBoundaries();
</pre>
Fonction à appeler obligatoirement pour préparer les périodes qui doivent être parcourues
<pre>
$p = $this->whObj->getNextEvent(BAB_PERIOD_NWDAY | BAB_PERIOD_VACATION | BAB_PERIOD_CALEVENT)
</pre>
parcourir les événements ; on peut filtrer sur le type avec le paramètre

<pre>
$events = $this->whObj->getEventsBetween(bab_mktime($startdate), bab_mktime($enddate), BAB_PERIOD_NWDAY | BAB_PERIOD_VACATION | BAB_PERIOD_CALEVENT);
</pre>
récupérer un tableau d'événements, les paramètres de date sont des timestamp pour délimiter la période

<pre>
$freeevents = $whObj->getAvailabilityBetween(bab_mktime($startdate), bab_mktime($enddate), $gap);

</pre>

Trouver les périodes de disponibilité entre 2 dates, $gap permet de définir la durée minimum des périodes à remonter (en secondes)
Pour ces 2 dernières fonctions, il faut que la période de récupération des infos soit incluse dans la période total qui a été utilisée à la création de l'objet

Développement d'une nouvelle fonctionnalité

2008-01-08T13:47:32Z

Patricia : /* Base de données */

== Sécurité ==

*Avez-vous suivi les recommandations en sécurité ?
*Injection SQL
*Cross Site Scripting

== Base de données ==

*Compatibilité MYSQL 3.23
*Compatibilité MYSQL 4
*Compatibilité MySQL 5
*Avez-vous testé avec la même version MySQL utilisée par le client?

== PHP ==

* Avez-vous suivi les recommandations en norme de codage ?
* Avez-vous testé sous PHP4 (version 4.1.2) ?
* Avez-vous testé sous PHP5 ?
* Est-ce que toutes les parties du code ont été déroulées durant les tests ?
* Durant les tests, est -ce que l'affichage des warnings et notices était activé ?
* Avez-vous testé avec la même version PHP utilisée par le client ?

== JavaScript ==

* Javascript activé
* Javascript désactivé
* Le javascript est-il fonctionnel sur internet explorer 5.5, 6.0, 7.0, firefox ?
* Le javascript est-il fonctionnel ou dégradé et non bloquant sur internet explorer 5.0, netscape ?

== Installation ==

* Test d'une nouvelle installation
* Test d'une mise à jour
* Installation sur un autre serveur que celui de la production
* Dans le cas d'un addon ou un script, est-ce que les tests ont été faits avec la version d'Ovidentia installée du client ?
* Avez-vous testé une installation avec une base «vierge» (Aucune donnée)
* Avez-vous testé sur l'environnement du client ?
* Avez-vous testé une désinstallation ?

== OS ==

* LINUX APACHE
* WINDOWS IIS
* WINDOWS APACHE

== Skin ==

* Avez -vous fait les tests avec le skin du client ?
* Les images sont-elles libres de droit ?
* L'avez vous testé sur IE ?
* L'avez-vous testé sur Firefox ?

== HTML ==

* Avez-vous testé l'accessibilité ?
* Le nom des classes utilisées est-il compatible avec tous les skins ?

== Divers ==

* Avez-vous fourni un fichier langue ?
* Ce fichier a t-il été relu pour les fautes d'orthographe ?

Accueil

2008-01-08T13:46:44Z

Patricia : /* Documentation des API */

== Contribuer au Wiki ==

{| cellpadding=0 cellspacing=5 width="100%"

|- valign="top"
||

Bienvenue sur le Wiki dédié au développement d'OVIDENTIA

Pour télécharger des documentations utilisateur et administrateur pour OVIDENTIA, vous pouvez utiliser le site communautaire [http://www.ovidentia.org/ Ovidentia.org]. Ce wiki, quant à lui contient une introduction au développement des modules ainsi que diverses documentations sur les nouvelles interfaces de programmation disponibles dans les versions actuelles et futures d'OVIDENTIA.

Avant de contribuer, vous pouvez vous familiariser avec les [[Règles d'usage du wiki|règles d'usage du wiki]].

Le développement d'OVIDENTIA est initié et géré par [http://www.cantico.fr Cantico] ([[Cantico:Accueil|wiki privé]])

|style="border: 1px solid lightgray;padding-left:1em;padding-right:0.5em;padding-bottom:0.5em;" width="40%"|

===[[Image:Helpcenter.jpg]] Que faire avec le wiki?===

* [[Développement de modules]]
* [http://www.ovidentia.org/?tg=articles&topics=56 Autres types de contributions]

|}

== Développement ==

{| cellpadding=0 cellspacing=5 width="100%"

|- valign="top"
|style="border: 1px solid gray;padding-left:1em;padding-right:0.5em;background:#E8F1FF;padding-bottom:0.5em;" width="50%"|
=== Règles de développement ===
* [[Règles de codage]]
* [[Sécurité]]
* [[Utilisation de Mantis]]
* [[Utilisation de CVS]] et gestion des versions
* [[Créer une archive de version]]
* [[Gettext]] : instruction d'utilisation pour les modules
* [[Implémentation de containers OVML dans un module]]
* [[Internationalisation]] : Améliorations de la gestion de l'internationalisation dans Ovidentia
* [[Accessibilité]]
* [[Développement d'une nouvelle fonctionnalité]]

=== Documentation des API ===
* [[Nouveau moteur de templates]]
* [[API des agendas]]
* [[Access Control List]], Droits d'accès
* [[Base de registre]]
* [[API de sélection d'utilisateurs]]
* [[API du gestionnaire de fichier]]
* [[API du gestionnaire d'événement]]
* [[API editeur]]
* [[API Addon - OVML]]
* [[Indexation]]

|valign="top" bgcolor="#E8F1FF" style="border-style:solid;border-width:1px;border-color:gray;padding-left:1em;padding-right:0.5em; padding-bottom:0.5em;" width="50%"|

=== Outils de développements ===

* [[Clients CVS]]
* [[Eclipse]]

=== Technologies à l'étude ===

* [[SyncML]]
* [[CardSpace]]
* [[WebDAV]]
* [[Plugins OpenSearch]]
* [[Communication entre les modules]]
* [[Les microformats]]
* [[Le standard UWA de Netvibes]]

=== Propositions d'améliorations ===

* [[Gestionnaire de fichiers]]
* [[Propositions pour Ovidentia 7]]
* [[OVML]]
* [[Gestion des skins]]
* [[Authentification par identifiant NT]]

|}

== Utilisation du wiki ==

Consultez le [http://meta.wikimedia.org/wiki/Aide:Contenu Guide de l'utilisateur] pour plus d'information sur l'utilisation d'un wiki.

* [http://www.mediawiki.org/wiki/Manual:Configuration_settings/fr Liste des paramètres de configuration]
* [http://www.mediawiki.org/wiki/Manual:FAQ/fr FAQ MediaWiki]

En anglais :
* [http://mail.wikipedia.org/mailman/listinfo/mediawiki-announce MediaWiki release mailing list]

__NOTOC__

Développement d'une nouvelle fonctionnalité

2008-01-08T13:40:08Z

Patricia : /* Divers */

Développement d'une nouvelle fonctionnalité

2008-01-08T13:39:41Z

Patricia : /* HTML */

== Sécurité ==

*Avez-vous suivi les recommandations en sécurité ?
*Injection SQL
*Cross Site Scripting

== Base de données ==

*Compatibilité MYSQL 3.23
*Compatibilité MYSQL 4
*Compatibilité MySQL 5
*Avez-vous testé avec la même version MySQL utilisée par le client?

== PHP ==

* Avez-vous suivi les recommandations en norme de codage ?
* Avez-vous testé sous PHP4 (version 4.1.2) ?
* Avez-vous testé sous PHP5 ?
* Est-ce que toutes les parties du code ont été déroulées durant les tests ?
* Durant les tests, est -ce que l'affichage des warnings et notices était activé ?
* Avez-vous testé avec la même version PHP utilisée par le client ?

== JavaScript ==

* Javascript activé
* Javascript désactivé
* Le javascript est-il fonctionnel sur internet explorer 5.5, 6.0, 7.0, firefox ?
* Le javascript est-il fonctionnel ou dégradé et non bloquant sur internet explorer 5.0, netscape ?

== Installation ==

* Test d'une nouvelle installation
* Test d'une mise à jour
* Installation sur un autre serveur que celui de la production
* Dans le cas d'un addon ou un script, est-ce que les tests ont été faits avec la version d'Ovidentia installée du client ?
* Avez-vous testé une installation avec une base «vierge» (Aucune donnée)
* Avez-vous testé sur l'environnement du client ?
* Avez-vous testé une désinstallation ?

== OS ==

* LINUX APACHE
* WINDOWS IIS
* WINDOWS APACHE

== Skin ==

* Avez -vous fait les tests avec le skin du client ?
* Les images sont-elles libres de droit ?
* L'avez vous testé sur IE ?
* L'avez-vous testé sur Firefox ?

== HTML ==

* Avez-vous testé l'accessibilité ?
* Le nom des classes utilisées est-il compatible avec tous les skins ?

== Divers ==

* Avez-vous fourni un fichier langue?
* Ce fichier a-t-il été relu pour les fautes d'orthographe?

Développement d'une nouvelle fonctionnalité

2008-01-08T13:38:27Z

Patricia : /* HTML */

== Sécurité ==

*Avez-vous suivi les recommandations en sécurité ?
*Injection SQL
*Cross Site Scripting

== Base de données ==

*Compatibilité MYSQL 3.23
*Compatibilité MYSQL 4
*Compatibilité MySQL 5
*Avez-vous testé avec la même version MySQL utilisée par le client?

== PHP ==

* Avez-vous suivi les recommandations en norme de codage ?
* Avez-vous testé sous PHP4 (version 4.1.2) ?
* Avez-vous testé sous PHP5 ?
* Est-ce que toutes les parties du code ont été déroulées durant les tests ?
* Durant les tests, est -ce que l'affichage des warnings et notices était activé ?
* Avez-vous testé avec la même version PHP utilisée par le client ?

== JavaScript ==

* Javascript activé
* Javascript désactivé
* Le javascript est-il fonctionnel sur internet explorer 5.5, 6.0, 7.0, firefox ?
* Le javascript est-il fonctionnel ou dégradé et non bloquant sur internet explorer 5.0, netscape ?

== Installation ==

* Test d'une nouvelle installation
* Test d'une mise à jour
* Installation sur un autre serveur que celui de la production
* Dans le cas d'un addon ou un script, est-ce que les tests ont été faits avec la version d'Ovidentia installée du client ?
* Avez-vous testé une installation avec une base «vierge» (Aucune donnée)
* Avez-vous testé sur l'environnement du client ?
* Avez-vous testé une désinstallation ?

== OS ==

* LINUX APACHE
* WINDOWS IIS
* WINDOWS APACHE

== Skin ==

* Avez -vous fait les tests avec le skin du client ?
* Les images sont-elles libres de droit ?
* L'avez vous testé sur IE ?
* L'avez-vous testé sur Firefox ?

== HTML ==

* Avez-vous testé l'accessibilité ?
* Le nom des classes utilisées sont elles compatibles avec tous les skins ?

== Divers ==

* Avez-vous fourni un fichier langue?
* Ce fichier a-t-il été relu pour les fautes d'orthographe?

Développement d'une nouvelle fonctionnalité

2008-01-08T13:36:05Z

Patricia : /* Skin */

== Sécurité ==

*Avez-vous suivi les recommandations en sécurité ?
*Injection SQL
*Cross Site Scripting

== Base de données ==

*Compatibilité MYSQL 3.23
*Compatibilité MYSQL 4
*Compatibilité MySQL 5
*Avez-vous testé avec la même version MySQL utilisée par le client?

== PHP ==

* Avez-vous suivi les recommandations en norme de codage ?
* Avez-vous testé sous PHP4 (version 4.1.2) ?
* Avez-vous testé sous PHP5 ?
* Est-ce que toutes les parties du code ont été déroulées durant les tests ?
* Durant les tests, est -ce que l'affichage des warnings et notices était activé ?
* Avez-vous testé avec la même version PHP utilisée par le client ?

== JavaScript ==

* Javascript activé
* Javascript désactivé
* Le javascript est-il fonctionnel sur internet explorer 5.5, 6.0, 7.0, firefox ?
* Le javascript est-il fonctionnel ou dégradé et non bloquant sur internet explorer 5.0, netscape ?

== Installation ==

* Test d'une nouvelle installation
* Test d'une mise à jour
* Installation sur un autre serveur que celui de la production
* Dans le cas d'un addon ou un script, est-ce que les tests ont été faits avec la version d'Ovidentia installée du client ?
* Avez-vous testé une installation avec une base «vierge» (Aucune donnée)
* Avez-vous testé sur l'environnement du client ?
* Avez-vous testé une désinstallation ?

== OS ==

* LINUX APACHE
* WINDOWS IIS
* WINDOWS APACHE

== Skin ==

* Avez -vous fait les tests avec le skin du client ?
* Les images sont-elles libres de droit ?
* L'avez vous testé sur IE ?
* L'avez-vous testé sur Firefox ?

== HTML ==

* Avez-vous testé l'accessibilité?
* Le nom des classes utilisées sont elles compatibles avec touts les skins?

== Divers ==

* Avez-vous fourni un fichier langue?
* Ce fichier a-t-il été relu pour les fautes d'orthographe?

Développement d'une nouvelle fonctionnalité

2008-01-08T13:35:42Z

Patricia : /* Installation */

== Sécurité ==

*Avez-vous suivi les recommandations en sécurité ?
*Injection SQL
*Cross Site Scripting

== Base de données ==

*Compatibilité MYSQL 3.23
*Compatibilité MYSQL 4
*Compatibilité MySQL 5
*Avez-vous testé avec la même version MySQL utilisée par le client?

== PHP ==

* Avez-vous suivi les recommandations en norme de codage ?
* Avez-vous testé sous PHP4 (version 4.1.2) ?
* Avez-vous testé sous PHP5 ?
* Est-ce que toutes les parties du code ont été déroulées durant les tests ?
* Durant les tests, est -ce que l'affichage des warnings et notices était activé ?
* Avez-vous testé avec la même version PHP utilisée par le client ?

== JavaScript ==

* Javascript activé
* Javascript désactivé
* Le javascript est-il fonctionnel sur internet explorer 5.5, 6.0, 7.0, firefox ?
* Le javascript est-il fonctionnel ou dégradé et non bloquant sur internet explorer 5.0, netscape ?

== Installation ==

* Test d'une nouvelle installation
* Test d'une mise à jour
* Installation sur un autre serveur que celui de la production
* Dans le cas d'un addon ou un script, est-ce que les tests ont été faits avec la version d'Ovidentia installée du client ?
* Avez-vous testé une installation avec une base «vierge» (Aucune donnée)
* Avez-vous testé sur l'environnement du client ?
* Avez-vous testé une désinstallation ?

== OS ==

* LINUX APACHE
* WINDOWS IIS
* WINDOWS APACHE

== Skin ==

* Avez -vous fait les tests avec le skin du client?
* Les images sont-elles libres de droit?
* L'avez vous testé sur IE?
* L'avez-vous testé sur Firefox?

== HTML ==

* Avez-vous testé l'accessibilité?
* Le nom des classes utilisées sont elles compatibles avec touts les skins?

== Divers ==

* Avez-vous fourni un fichier langue?
* Ce fichier a-t-il été relu pour les fautes d'orthographe?

Développement d'une nouvelle fonctionnalité

2008-01-08T13:34:57Z

Patricia : /* JavaScript */

== Sécurité ==

*Avez-vous suivi les recommandations en sécurité ?
*Injection SQL
*Cross Site Scripting

== Base de données ==

*Compatibilité MYSQL 3.23
*Compatibilité MYSQL 4
*Compatibilité MySQL 5
*Avez-vous testé avec la même version MySQL utilisée par le client?

== PHP ==

* Avez-vous suivi les recommandations en norme de codage ?
* Avez-vous testé sous PHP4 (version 4.1.2) ?
* Avez-vous testé sous PHP5 ?
* Est-ce que toutes les parties du code ont été déroulées durant les tests ?
* Durant les tests, est -ce que l'affichage des warnings et notices était activé ?
* Avez-vous testé avec la même version PHP utilisée par le client ?

== JavaScript ==

* Javascript activé
* Javascript désactivé
* Le javascript est-il fonctionnel sur internet explorer 5.5, 6.0, 7.0, firefox ?
* Le javascript est-il fonctionnel ou dégradé et non bloquant sur internet explorer 5.0, netscape ?

== Installation ==

* Test d'une nouvelle installation
* Test d'une mise à jour
* Installation sur un autre serveur que celui de la production
* Dans le cas d'un addon ou un script est-ce que les tests ont été faits avec la version d'Ovidentia installée du client?
* Avez-vous testé une installation avec une base «vierge» ( Aucune donnée )
* Avez-vous testé sur l'environnement du client?
* Avez-vous testé une désinstallation?

== OS ==

* LINUX APACHE
* WINDOWS IIS
* WINDOWS APACHE

== Skin ==

* Avez -vous fait les tests avec le skin du client?
* Les images sont-elles libres de droit?
* L'avez vous testé sur IE?
* L'avez-vous testé sur Firefox?

== HTML ==

* Avez-vous testé l'accessibilité?
* Le nom des classes utilisées sont elles compatibles avec touts les skins?

== Divers ==

* Avez-vous fourni un fichier langue?
* Ce fichier a-t-il été relu pour les fautes d'orthographe?

Développement d'une nouvelle fonctionnalité

2008-01-08T13:34:33Z

Patricia : /* PHP */

== Sécurité ==

*Avez-vous suivi les recommandations en sécurité ?
*Injection SQL
*Cross Site Scripting

== Base de données ==

*Compatibilité MYSQL 3.23
*Compatibilité MYSQL 4
*Compatibilité MySQL 5
*Avez-vous testé avec la même version MySQL utilisée par le client?

== PHP ==

* Avez-vous suivi les recommandations en norme de codage ?
* Avez-vous testé sous PHP4 (version 4.1.2) ?
* Avez-vous testé sous PHP5 ?
* Est-ce que toutes les parties du code ont été déroulées durant les tests ?
* Durant les tests, est -ce que l'affichage des warnings et notices était activé ?
* Avez-vous testé avec la même version PHP utilisée par le client ?

== JavaScript ==

* Javascript activé
* Javascript désactivé
* Le javascript est-il fonctionnel sur internet explorer 5.5, 6.0, 7.0, firefox?
* Le javascript est-il fonctionnel ou dégradé et non bloquant sur internet explorer 5.0, netscape?

== Installation ==

* Test d'une nouvelle installation
* Test d'une mise à jour
* Installation sur un autre serveur que celui de la production
* Dans le cas d'un addon ou un script est-ce que les tests ont été faits avec la version d'Ovidentia installée du client?
* Avez-vous testé une installation avec une base «vierge» ( Aucune donnée )
* Avez-vous testé sur l'environnement du client?
* Avez-vous testé une désinstallation?

== OS ==

* LINUX APACHE
* WINDOWS IIS
* WINDOWS APACHE

== Skin ==

* Avez -vous fait les tests avec le skin du client?
* Les images sont-elles libres de droit?
* L'avez vous testé sur IE?
* L'avez-vous testé sur Firefox?

== HTML ==

* Avez-vous testé l'accessibilité?
* Le nom des classes utilisées sont elles compatibles avec touts les skins?

== Divers ==

* Avez-vous fourni un fichier langue?
* Ce fichier a-t-il été relu pour les fautes d'orthographe?

Développement d'une nouvelle fonctionnalité

2008-01-08T13:33:36Z

Patricia : /* Sécurité */

== Sécurité ==

*Avez-vous suivi les recommandations en sécurité ?
*Injection SQL
*Cross Site Scripting

== Base de données ==

*Compatibilité MYSQL 3.23
*Compatibilité MYSQL 4
*Compatibilité MySQL 5
*Avez-vous testé avec la même version MySQL utilisée par le client?

== PHP ==

* Avez-vous suivi les recommandations en norme de codage?
* Avez-vous testé sous PHP4 (version 4.1.2) ?
* Avez-vous testé sous PHP5?
* Est-ce que toutes les parties du code ont été déroulées durant les tests?
* Durant les tests est -ce que l'affichage des warnings et notices était activé?
* Avez-vous testé avec la même version PHP utilisée par le client?

== JavaScript ==

* Javascript activé
* Javascript désactivé
* Le javascript est-il fonctionnel sur internet explorer 5.5, 6.0, 7.0, firefox?
* Le javascript est-il fonctionnel ou dégradé et non bloquant sur internet explorer 5.0, netscape?

== Installation ==

* Test d'une nouvelle installation
* Test d'une mise à jour
* Installation sur un autre serveur que celui de la production
* Dans le cas d'un addon ou un script est-ce que les tests ont été faits avec la version d'Ovidentia installée du client?
* Avez-vous testé une installation avec une base «vierge» ( Aucune donnée )
* Avez-vous testé sur l'environnement du client?
* Avez-vous testé une désinstallation?

== OS ==

* LINUX APACHE
* WINDOWS IIS
* WINDOWS APACHE

== Skin ==

* Avez -vous fait les tests avec le skin du client?
* Les images sont-elles libres de droit?
* L'avez vous testé sur IE?
* L'avez-vous testé sur Firefox?

== HTML ==

* Avez-vous testé l'accessibilité?
* Le nom des classes utilisées sont elles compatibles avec touts les skins?

== Divers ==

* Avez-vous fourni un fichier langue?
* Ce fichier a-t-il été relu pour les fautes d'orthographe?

Accessibilité

2008-01-08T13:32:34Z

Patricia : /* Points a traiter pour le niveau bronze accessiweb */

==Points à traiter pour le niveau bronze accessiweb==

5. Tableaux.

'''5.1 : L'attribut SUMMARY est-il présent et pertinent ?'''

Commentaire :
L'attribut "SUMMARY", s'il est correctement rempli, peut donner une information supplémentaire sur l'utilisation des tableaux dans une page Web pour certains internautes, aveugles par exemple. Dans une page qui contient une barre de menu, créée à partir d'un tableau HTML, l'attribut SUMMARY="Barre de menu" va donner à l'utilisateur une indication supplémentaire sur la fonction de ce tableau.

'''5.2 : Dans un tableau de données, la balise CAPTION est-elle utilisée pour donner un titre au tableau ?'''

Commentaire :
Plutôt que d’utiliser un texte mis en forme pour titrer un tableau, il est plus judicieux d’utiliser la balise CAPTION, qui est la balise dédiée pour afficher un titre dans un tableau.

'''5.3 : Dans les tableaux de données, y a t-il des en-têtes de colonnes appropriées ?'''

Commentaire :
Dans un tableau de donnée, en HTML, la balise TH spécifie les en-têtes de colonnes et permet aux utilisateurs d’aides techniques de savoir par l'intermédiaire de la synthèse vocale qu’il s’agit d’une en-tête de colonne.

'''5.4 : Dans un tableau de données, y a t-il un attribut HEADERS présent pour relier chacune des cellules du tableau ?'''

Commentaire :
Correctement placé dans un tableau de données, les attributs HEADERS et ID permettent de relier le contenu d'une cellule au titre de colonne auquel il est associé. L’utilisation des attributs HEADERS et ID permet de lier chaque cellule à l’en-tête qui lui est attachée. Une personne n’ayant qu’une vision linéaire de ce tableau pourra donc en permanence savoir à quelle en-tête est attachée la cellule dans laquelle elle se trouve.

'''5.6 : Dans un tableau de mise en forme, le contenu est-il correctement ordonné ?'''

Commentaire :
Dans les tableaux de mise en forme, les informations doivent être ordonnées de telle manière qu'elles puissent être affichées dans un ordre équivalent lors d'une lecture linéaire de la page. L'organisation de l'information à l'intérieur d'un tableau de mise en page doit faire l'objet de beaucoup d'attention. Les outils actuels de développement HTML ont tendance à imbriquer les tableaux les uns dans les autres. Il en résulte parfois des différences entre le rendu visuel de l'information sur un navigateur graphique et le rendu textuel, respectant l'organisation du code HTML, d'un navigateur textuel de type Lynx par exemple.

'''8.6 : Le contenu de la balise TITLE est-il différent d'une page à l'autre ?'''

Commentaire :
Un même titre sur les différentes pages d'un site peut induire les utilisateurs en erreur. En effet, le titre de la page est la première information rendue à l’écran et les répétitions d’un même titre entre plusieurs documents différents, peuvent créer une perte de repères.

'''8.7 : Les changements de langue dans une page sont-ils signalés ?'''

Commentaire :
Lorsqu'un changement de langue intervient dans une page, il est nécessaire de le signaler à l'utilisateur. En effet, en cas d'utilisation d'une synthèse vocale, celle-ci changera automatiquement de langue à la détection de la balise LANG qui spécifie qu'un mot ou une phrase est dans une langue différente.

11. Formulaires.

'''11.1 : La balise LABEL et les attributs correspondants (ID, FOR) sont-ils présents ?'''

Commentaire :
Dans le cas d’une page en HTML, la balise LABEL associée aux attributs ID et FOR permet de relier directement le champ de saisie au texte qui lui est associé. Cela permet aux personnes naviguant à l’aide d’une aide technique de définir sans ambiguïté à quel champ de saisie correspond le texte associé.

'''13.3 : Le visiteur est-il averti lorsque de nouvelles fenêtres apparaissent ?'''

Commentaire :
Deux notions s'apparentent à l'expression "nouvelles fenêtres" : fenêtre de navigateur et pop-up. L'ouverture d'une fenêtre de navigateur s'effectue grâce à une commande HTML alors que la pop-up s'ouvre par l'intermédiaire d'un script sur le poste client. Dans certains cas, les personnes utilisant des navigateurs qui ne gèrent pas les scripts côté client ou qui désactivent volontairement les scripts dans leur navigateur n'auront donc pas accès à l'information contenue dans la pop-up. L'ouverture automatique d'une pop-up dès le chargement d'une page rend la lecture difficile, notamment pour les personnes utilisant des aides techniques pour naviguer. L'ouverture de nouvelles fenêtres, surtout lorsque l'utilisateur n'est pas prévenu, n'est pas conseillée.

==Points a traiter pour le niveau argent accessiweb==

5. Tableaux.

'''5.5 : Dans un tableau de données, lorsqu'un titre de colonne dépasse 15 caractères, l'attribut ABBR est-il utilisé ?'''

Commentaire :
Un titre de colonne (TH) est long lorsqu'il dépasse 15 caractères. L'attribut ABBR permet à certaines aides techniques de reprendre l'abréviation du titre de colonne pour l'associer à la cellule qui lui fait référence. Il faut veiller à ce que le contenu de l'attribut ABBR soit pertinent et soit en rapport avec le contenu de l'en-tête de colonne auquel il se réfère. Lorsqu'un tableau de données est correctement construit, une synthèse vocale est capable d'indiquer à l'utilisateur à quel titre de colonne se réfère une cellule. Quand le titre de colonne est long (exemple : Marque du véhicule), l'attribut ABBR va obliger la synthèse vocale à n'annoncer que le mot "marque". L'utilisation de l'attribut ABBR permet un confort de lecture supplémentaire pour les utilisateurs de synthèses vocales.

11. Formulaires.

'''11.4 : La balise FIELDSET est-elle présente pour encadrer des blocs d'information de même nature ?'''

Commentaire :
Dans un même formulaire, plusieurs champs de saisie de même nature (les champs "nom", "prénom", "date" et "lieu de naissance" constituent le groupe de champs "Etat civil") peuvent être regroupés par l'intermédiaire de la balise FIELDSET (dans le cas d'une page en HTML).

'''11.5 : La balise LEGEND est-elle présente pour donner un titre au bloc d'informations encadré par la balise FIELDSET ?'''

Commentaire :
Dans le cas d'une page en HTML, l'utilisation de la balise LEGEND (associée à la balise FIELDSET) permet de donner un titre à chaque bloc d'information.

Internationalisation

2008-01-08T13:27:08Z

Patricia : /* Envoi d'email */

== Traduction des entités de contenu ==

Thèmes d'articles, catégories ...

Le problème sera résolu par l'intégration du plan de site dans le noyau

== Envoi d'email ==

La plupart des email envoyés par ovidentia sont internationalisés, mais la langue utilisée pour la traduction est celle de la configuration de l'expéditeur du message. Il faut utiliser une autre fonction de traduction qui tient compte des options du destinataire.

Fonction disponible à partir d'ovidentia 6.2.0 :
<pre>
include_once $babInstallPath."utilit/translateincl.php";
bab_userTranslate($id_user, 'string to translate');
</pre>

Internationalisation

2008-01-08T13:26:40Z

Patricia : /* Envoi d'email */

== Traduction des entités de contenu ==

Thèmes d'articles, catégories ...

Le problème sera résolu par l'intégration du plan de site dans le noyau

== Envoi d'email ==

La plupart des email envoyés par ovidentia sont internationalisés, mais la langue utilisée pour la traduction est celle de la configuration de l'expéditeur du message. Il faut utiliser une autre fonction de traduction qui tient compte des options du destinataire.

fonction disponible à partir d'ovidentia 6.2.0 :
<pre>
include_once $babInstallPath."utilit/translateincl.php";
bab_userTranslate($id_user, 'string to translate');
</pre>