A ce titre, la plupart de l’implémentation du filtre à lieux  dans la section GetConf de la classes, et dans la définition de l’ensemble des éléments de la variable $InitInfo.

Pour mettre en oeuvre les filtres, le plus simple à mettre en oeuvre consiste à ajouter le choix des colonnes visibles. A cette fin , le gabarit html est déjà conçu. Il suffit donc de l’initialiser, en fournissant l’ensemble des éléments nécessaire à son initialisation correct.

Dans notre exemple, nous partons dans le contexte que l’action courante est : ‘listing’

Section dans la function GetConf

Dans un premier temps, ajouter une variable dans la class

  /**
    @var array info all tabs for filter listings
  */
  public static $allfields = array();

Puis dans la méthode GetConf, apres les section de definition des var static, et constante JSONSTATMENT, placer la definition de l’ensemble des colonne qui seront disponible pour cette selection.
/**
@remarks this define col theader title, and ajust html code
Just for Edit listing
*/

self::$allfields = array(
	'o.orders_id' => array(
		'sort'=>true,
		'text'=>__('orders table heading order id'),
		'width'=>'2%',
		'class'=>'tcenter',
		'default'=>true,
		),
                ....
             );

Puis construire le début de la structure des theader ou tfooter et ou modele. Dans notre exemple, nous allons définir 3 colonne supplémentairement qui seront affiché systématiquement. C’est le cas pour les 2 première colonnes, fournissant le bouton plie/déplie du détail, et la colonne pour sélectionner cette ligne. Enfin, nous placeront aussi la colonne action.

/**
	@remarks Construct all list , fields , th/td
*/
self::$InitInfo['theader']['listing']=array(
		0 =>array('width'=>'2%', 'class'=>'tcenter', 'txt'=>' ' ),
		1 =>array('width'=>'2%', 'class'=>'tcenter', 'txt'=>' ' ),
		);
self::$InitInfo['tfooter']['listing']=self::$InitInfo['theader']['listing'];

self::$InitInfo['modele']['listing']=array(
				0 =>false,
				1 =>false,
	);



self::$InitInfo['modele']['listing']['action']=false;
self::$InitInfo['theader']['listing']['action']= array( 'class'=>'row_action', 'txt'=>__('table heading action') );
self::$InitInfo['tfooter']['listing']['action']= array( 'class'=>'row_action', 'txt'=>__('table heading action') );

Pour ce qui est de la boucle dynamique, nous utiliseront le control sur le tableau de filtre de la session utilisateur.
Dans noter contexte, nous utiliserons une boucle comme suit :

// min  fields and not view directly colonne fields
$listfield = 'o.orders_prefix, s.status_color as orders_status_color,';
// put in
if(isset($_SESSION['filters'][__CLASS__]['allfields']))
	$_SESSION['filters']['allfields'] = $_SESSION['filters'] [__CLASS__]['allfields'];
else
	$_SESSION['filters']['allfields'] = array();

	$in_session = $_SESSION['filters']['allfields'];
// check and appli
foreach(self::$allfields  as $key=>$row){
	$clean = substr($key, (strpos($key, '.')+1));

	if(is_array($row)){
		$txt = $row['text'];
		$alias = (isset($row['alias'])? $row['alias'] : $clean);
		$css = (isset($row['class'])? $row['class'] : 'tcenter');
		$width = (isset($row['width'])? $row['width'] : '5%');
	}
	else{
		$txt = $row;
		$alias = $clean;
		$css = 'tcenter';
		$width = '5%';
	}

        if(
	( isset($in_session[$clean]) &&  (string)$in_session[$clean] == 'on' )
	|| ( count($in_session) <=1  && ( is_array($row) && isset($row['default']) &&  $row['default'] == true) )
	) {
		$_SESSION['filters']['allfields'][$clean] = 'on';
		/**
			@remarks this define col theader title, and ajust html code
		*/
		self::$InitInfo['theader']['listing'][]= array( 'width'=>$width, 'class'=>$css, 'txt'=>$txt);
		self::$InitInfo['tfooter']['listing'][]= array( 'width'=>$width, 'class'=>$css, 'txt'=>$txt );
		/**
			@remarks this define col in table, and if is possible sort
		*/
		self::$InitInfo['modele']['listing'][$alias]=true;

		if($clean !=$alias)
			$listfield .=$key.' as '.$alias.',';
		else
			$listfield .=$key.',';
	}
	}

Puis la transmissions du tableau complet des options de filtre disponible

 self::$InitInfo['allfields']['listing'] = self::$allfields ;

Et pour finir l’activation proprement dite des tabs des filtres

/**
 @remarks Active forms filter
*/
self::$InitInfo['tfilter']['listing']=array(
/* Premier filtre spécifique a cette page */
					array(
					'title'=>__('orders filter tab clause'),
					'content'=>tep_get_include_contents(__CLASS__.'/filter.clause'),
                 			),
/* Second filtre utilisant le ModTwo et le choix des colonnes  */
				array(
					'title'=>__('orders filter tab fields'),
					'type'=>'listfield'
				),
			);

Enfin la transmission des champs a utiliser dans la requetes sql

/**
		@remarks Put detail for listing methode
	*/
	self::$InitInfo['adjust']['listfields'] = substr($listfield, 0,-1);

Section dans la function check_action

La section de prise en charge du formulaire , dans le switch des actions

/**
	@remarks specific save in session value filters
*/
case 'filters':
	$_SESSION['filters'][__CLASS__]['allfields'] =array();
	foreach($_POST['allfields'] as $key=>$row){
		if( $row =='on' )
			$_SESSION['filters'][__CLASS__]['allfields'][$key] = 'on';
		else
			unset($_SESSION['filters'][__CLASS__]['allfields'][$key]);
	}

	$_SESSION['filters'][__CLASS__]['viewstatus'] =array();
	foreach($_POST['viewstatus'] as $key=>$row){
		if( $row =='on' )
			$_SESSION['filters'][__CLASS__]['viewstatus'][$key] = 'on';
		else
			unset($_SESSION['filters'][__CLASS__]['viewstatus'][$key]);
	}

	tep_redirect(tep_href_link(self::FILENAME));
break;

Section dans la function GetDBValue

Modifier la requêtes produisant le listing, en y portant la var des la liste des champs à extraire de la base.

$adjust=new objectInfo(self::$InitInfo['adjust']);

$query_raw = "select distinct ".$adjust->listfields." from " ....

Lors de l’ajout de donnée, la prise en charge de plusieurs langues ce fait naturellement, en ajoutant une langue dans la gestion de langue.

Il est toutefois important de savoir que cette langue ne sera considéré comme active, que dans la mesure ou les fichiers de langue correspondant seront présent. par defaut, seul les fichiers public sont recherchés.

Si le dossier de langue public n’est pas présent, alors la langue sera considéré comme inactive, et donc l’ajout de donnée ne ce fera que sur les langue active.

Dans ce contexte, aucun mécanisme de rattrapage des ligne manquante dans la base n’existe, il est donc important de mettre en place les fichier avant l’installation de la langue …….

Dans ces page de listing, il peut être nécessaire d’intégrer des appels js (Toolip par ex) surle contenu de ce listing.  Il est donc nécessaire d’utiliser la fonction de callback contenu dans la classes oscss_cstr
Soit:

oscss_cstr::CallBack('Toolip();');

Note

• la fonction Callback support un second argument, qui précise si le paramètre principal correspond à du code, ou un liens vers un fichier (code|file). Toutefois, à l’heure de ces lignes seul le mode par défaut est supporté.
• la fonction Callback support un troisième argument, qui précise la pile dans laquelle la valeur sera stocké. Toutefois, à l’heure de ces lignes seul la pile par défaut est implémenté.

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

Le mode d’encryptage est déterminé par le fichier configure, et peut être différente entre le back-office et le front office.

Trois modules sont fournis

• Classic qui correspond à l’encryptage original des version précédente d’oscss, et d’oscommerce. Il couple un cryptage md5 à une clef interne unique
• Md5, une classique empreinte
• Sha1, le cryptage utilisé par défaut lors d’une nouvelle installation

Voir les fichiers configure

exemple

    /**
    @var Define class use for encrypt password
    Value possible:
    - Classic normal in oscommerce mode
    - Md5 special for acces by other mode
    - Sha1 new mode
    */
    $conf['ModPassword'] = 'Classic';

Pour forcer le redimensionement en carré, en utilisant le module present, il faut placer dans le fichier du template :

image_ratio::SetModele('Carre');

Pour utiliser un watermark

Ajouter dans la configuration, le texte souhaité, puis activer l’utilisation du watermark avec:

image_ratio::SetModeleSetWatermark(true);

Il s’agit d’un petite evolution de ces modules. Le module DOIT renvoyer le type de donnée qu’il traitent. C’est cette indication qui est utilisé dans les boucles associées au modules.

Pour corriger ce probleme, ajouter dans les function  » in_obj_xxx », dans la boucle de traitement des donnée , l’informations comme suit:
Avant

 while ($listing_version_products = $res->fetchAssoc()){

 $pd=product::get_item($listing_version_products['products_id']);

 $pd->aca=$aca_listing->return_db_min($listing_version_products['products_id']);

 $p[]=$pd;

 }

 return new objectInfo(array('title'=>__('table heading version products') , 'content'=>$p));

Apres

while ($listing_version_products = $res->fetchAssoc()){
 $pd=product::get_item($listing_version_products['products_id']);
 $pd->aca=$aca_listing->return_db_min($listing_version_products['products_id']);
 $pd->type='product';
 $p[]=$pd;
 }

return new objectInfo(array('title'=>__('table heading version products') , 'content'=>$p ,'type'=>'product'));

$current=$page->new_class(‘customer’);

- Utilisation du moteur interne
La génération du pdf à lieu exclusivement par le back-office.
- Utilisation d’un moteur externe
Pas de génération de pdf disponible dans le back-office.

- Conclusion

Aussi, pour que le client dans sont espace (cf module account/history) le pdf soit disponible, il doit être présent.

La lecture ou téléchargement de ce fichier est assuré par l’appel à la page documents.php

L’exemple concerne la gestion des commandes, et les statut, en attente, en preparation, livré et annulé.

La nouvelle nomenclature sera ainsi
- en attente id 1
- payé id 2
- en preparation id 3
- expedié id 4
- livré id 5
- cloturé id 6
- annulé id -1

D’autre part, il est maintenant possible, et recommandé, que les module qui ajoute des statut, soit des statut enfant de ceux cité au dessus

C’est a dire, que un statut « payé par CB « , sera un statut avec l’id 21.
Il appartiendra a la section des statut payé, et precisera par cb.

Pour attribbuer un statut à sont pére, il faut respecter l’ecriture ci dessous:
pere + num
21 Pour pere payé
12 Pour pere en attente

L’etat des commande et du comportement de la boutique, sera donc basé sur le pere du statut courant.
Toutefois cette nuance permet au module de genere leur propre statut, et ainsi de suivre en interne du module la progression.

Enfin les liste de commande ne contiendront que les statut > 0. C’est a dire que les listing ne publierons pas les commande annulé, ou avec un statut negatif