Les datatypes

mise à jour : 22/04/2012

La notion de datatype est apparu sur les versions 2.1.0 et ultérieure; Cette notion visent à rassembler au sein d’un fonctionnement normalisé l’ensemble des données publiés.

Les données publiées rassemblent les données de contenu , hors de donnée du fonctionnement propre du moteur.

Liste non exhaustive:

  • Les RootListing, transversales , elle permette de hiérarchiser les donné enfants: ( categorie, manufacturer )
  • Les donnée enfants, ordonnancé en listing , et contenant une page d’info unique : ( product, content, … )

Cette approche doit permettre de manipuler les données avec des outils synthétique, et dont la forme et les appels sont identiques.

D’autre part, ces données étant dynamique, elle peuvent dont ajouter/modifié le comportement des page public, quant à gestion et l’affichage.

 

dans les exemples et explications suivantes, nous partons sur la notion d’un datatype « xxx », couplé au categories

 

Lors de l’ajout d’un nouveau datatype, respecter les règles suivantes:

  • le nom du datatype doit être unique, et ne pas être déjà utilisé
  • le nom du datatype doit être au singulier
  • certain fichier sont optionnels, toutefois la

 

Les tables de données d’un datatype

Les tables doivent respecter la nomenclature de nommage courante :

  • osc_datatype
  • osc_datatype_description (gestion multi-langue)
  • osc_datatype_extra (optionnnel) peut être aussi remplacer par des extras complexe (cf extras des products)
  • osc_datatype_to_categorie (optionnel – liaison avec les categories)

 

La nomenclature des tables est importante, elle contient le nom des liaison entre datatype, et est utilisé dans la gestion avancé des tables et des backups. il est donc important de conserver une structure  de ce type.

Petit rappel :

  • séparateur  « _ » p
  • le non du datatype enfants en premier
  • le nom de la liaison en second, avec ‘to’ comme séparateur

 Les defines  de constantes associé à l’exploitation des tables dans le core sont assuré par le module Data_xxx. Tans dans le backoffice que le frontoffice. La désactivation d’un module rend donc les tables inaccessible via les constante !!

 

Les clef de tables, et définition de la clef primaire de chaque tables doit faire preuve d’une attention particulière. Ce sont ces éléments qui définissent la capacité du core a manipuler les tables dans différents contextes.  les clef primaires sont entre autre utilisé dans la manipulation du nombre de langue, et la duplication automatique des entrée nécessaire au bon fonctionnement du module.

Les fichiers et dossiers

Les define qui construise les constantes de nommage des fichier sont assuré par le modules Data_xxx.

Dossier /common/

Les modules sont nommé ‘Data_’.xxx ou xxx représente le nom du datatype.

Au sein de ce dossier centralisé, les drivers « datatype_drivers » assure la prise en charge des datatypes. Ce sont ces modules, qui détermine, en fonction des arguments GET et du nom de la page, si la page courante correspond a ce datatype, et le pré-chargement des classes spécifique au datatype courant.

D’autre part, ce module assure aussi la liaison avec la class seo, pour la construction des url spécifique à ce datatype, ainsi qu’au élément nécessaire à la construction du htaccess.

 

Dossier admin

le dossier admin peut quant à lui s’ordonner en fonction des besoins spécifique au datatype. Nous retrouverons toutefois les modules suivant

  • /modules/pages/datatypes.php  (gestion listing / affichage / édition des données)
  • /modules/datatype/ (Dossier  specifique au sous module du datatype courant)
  • /classes/drivers/sqldatatype.php la class sql de manipulation des données de manière structuré

Dossier public

La structure du dossier public peut être plus ou moins ajusté, nous respecterons néanmoins la nomenclature suivante:

  • /classes/drivers/data/datatype.php (la class public principale de manipulation des données de ce datatype)
  • /content/ (le fichier nécessaire à la visualisation d’une datatype unique – défini dans le module Data_datatype de  common)

 

Transversalité de certain module entre eux

Certain module de datatype sont un peu spécifique, compte tenu qu’il inter-agissent avec d’autre module de datatype (categorie / fabricant).

Il est à la charge du module transversale de prendre en charge le couplage (listing requête sql) des autres datatypes;

Une variable de configuration est définit pour chaque RootListing nommé « DATATYPES_ROOTLISTING__xxx » du nom du datatype, elle contient la liste (séparé par une virgule) des datatype auquelles elle est couplé.

 

Dev/GenerCode Modele : datatype

Un modèle de datatype existe dans la section dev/GenerCode; il s’agit d’un générateur de code succinct qui ce contente de construite l’ensemble de la structure de base d’un datatype de type contenu enfant ( idem product/content).

L’intérêt de cette méthode, et que l’extension de votre datatype construit, il vous suffit de l’ajuster à vos besoin.  les fichiers existe dans une extension destiné à l’installateur d’oscss, que ce soit en backoffice ou frontoffice. De même que l’ensemble des tables, liaison, define , entrée dans les menu, etc.. sont mise en œuvre entre les fichier et l’install.xml

Les tables créer ne contiennent que les champs minimaux structurel. Charge a vous d’ajuster les colonnes ainsi que les gabarit html et gestion des enregistrement.

 

Gestion / Intégration dans le front office, exploitation et usage

 

l’usage des datatypes, dans l’environnement public, et l’intégration de vos template reste assez transparent. Les listing sont gérer sans

 

Les Listing

le listing ce construit automatiquement sur la base des catégories. La liaison du datatype aux catégorie, vous à donné accès à la création de catégorie typée sur ce datatype, soit xxx. La Classes listing de la section core_page du dossier classes, assurera donc la recherche ordonnée des entrées de ce datatype dans cette/ces categories.

note: le calcul effectué ne rassemble que les id du datatype, et non les données de chaque ligne.

Aussi , le listing se construira automatiquement , et son détail (le détail des données de chaque ligne ) sera assuré par le module standard ‘listing.php’ des modules non-typés (il vous est bien sûr possible de personnaliser ces appels et de construire un module spécifique destiné au listing).

 

La page xxx_info.php | info_xxx.php

Cette page est la section destinée à l’affichage unique de cette ressource. Elle sera donc très dépendantes des colonnes des tables principales , et des données associées.

Il est donc nécessaire de construire cette page sur mesure.

Rappel :

le détail de la ressource

$object_data = xxx::get_item($id);

 

sur la page info, l’appel est déjà calculé, aussi un simple appel à la pile suffit:

$object_data =$page->GetVar('xxx');

alias – rétro-compatibilité

$object_data =$page->the_var('xxx');

L’appel à vos sous module aca:

$module=$page->_call('xxx','ret_modules');

 

 

Liens et SEO

La gestion de la ré-écriture d’url , accompagné de l’ajustement du htaccess reste absolument transparente. Noter que vous devez avoir mise en place un module aca header_tag dans ce datatype coté admin.

L’ensemble de la ré-ecriture sera assuré par le Data_xx.  Quelque soit le module de ré-ecriture choisi.

htaccess

Le contenu du fichier est produit dans le back-office, celui-ci prendra en charge tous les datatype présent lors de son exécution. Si vous activez un nouveau datatype, pensez a mettre a jour votre htaccess public

 

La recherche avancé

La encore, c’est le Data_xxs qui va prendre en charge la gestion de la construction des requêtes sql, couplé avec les catégories. Noté que si vous souhaitez couplé la recherche à un formulaire plus complet et éventuellement avec d’autre Rootlisting (categorie en est un , manufacturer un autre); vous devrez ajuster le Data_xxx

Seuls les critères de base sont configurés.

Un gabarit html (fichier .gab)  peut être définis dans le tableau retourné par le datatype, dans ce contexte, le sous gabarit utile apporte les champs de formulaire complémentaire

Les commentaires sont fermés.