Re: avancement des travaux

Eric Daspet wrote:

>>C'est pas tout a fait terminé, mais c'est en bonne voie. J'arrive a 
>>créer des catégories ayant des catégories parentes multiples, dans 
>>n'importe quelle langue
>>    
>>
>
>Chouette
>Enfin ceci dit si tu as problème avec les langues c'est à mon avis
>quelque chose d'annexe, il vaut mieux avoir quelque chose qui marche
>sans les langues si ça te permet d'aller plus vite. 
>  
>

ca marche bien pour l'instant. Je les gere uniquement dans la donnée XML 
pour l'instant, puisque je n'ai pas besoin d'indexer le nom et la 
description de la catégorie (qui sont les seules données localisées). 
Quand on mettra en place le systeme de recherche, avec un indexage mot a 
mot, il faudra faire un peu gaffe.

>>quand on retire des infos d'une liste, comme on sait qu'elle a bougé au 
>>niveau du cache ? En effet, la date de derniere modification de ses 
>>éléments n'a pas forcément bougé ... Par exemple :
>>
>>si je prend les catégories
>>- cat1
>>- cat2
>>- cat3
>>
>>Si je retire cat3, la date de derniere modif n'aura pas changé (ca sera 
>>max(cat1, cat2) ), mais pourtant la liste ne sera plus la meme ... grrr ...
>>    
>>
>
>Pfiou, bonne question. Peut être qu'en interne il faudra gérer une date
>de dernière modif au niveau catégorie, à mettre à jour à chaque fois
>qu'on touche à une catégorie. Ce n'est pas très glorieux mais c'est
>efficace.
>
>J'ai bien une autre solution mais elle nécessiterait de faire au moins 4
>requetes SQL, ce qui n'est pas top vu qu'on parle de l'information qui
>nous sert de déclenchement de cache (c'est censé etre une info peu
>couteuse à obtenir).
>  
>

je veux bien que tu l'expose ;-)

si on regarde la date de derniere modif de la table des catégories, on a 
aussi le pb de savoir si la date de derniere modif est effectivement la 
vraie date de derniere modif (donc il faut regarder la date de derniere 
modification sur les catégories, comparer etc ...)

En gros, pour faire simple, on pourrait faire en sorte que si on change 
un petit truc ca invalide tout, mais on perd tout l'interet du cache ... 
ouiinn ...

>  
>
>>il faut que je fasse l'invalidation du cache quand la feuille de style a 
>>changé
>>    
>>
>
>Dans l'idéal je préfère que tu ne touches pas au cache résultat. Au lieu
>d'invalider le cache c'est aussi bien que tu stockes la date à chaque
>fois que ça arrive, et que tu la réutilises plus tard comme date de
>modif minimum. Ainsi tu gardes l'abstraction (tu ne touches pas au
>cache).
>  
>
au niveau du module, je gere deux caches. Par exemple, j'ai écrit le 
module SubCategories, qui permet de lister les catégories descendant 
d'une catégorie donnée.

Je veux lister les catégories descendant de la racine, ROOT :

/*

initialisation du module, il demande les infos dont il a besoin au 
controlleur
le controlleur lui dit qu'il veut les catégories descendant de ROOT, et 
une sortie en XHTML

*/

$c = new ModuleSubCategories ;

/*

on regarde si la donnée XHTML est valide

*/

$c->isValid() ;

/*

si on a besoin de la récuperer, on la récupere

*/

$c->getData() ;

/*

la il s'est passé plusieurs choses :
- si la donnée était bonne, [0] ModuleSubCategories a renvoyé son cache 
XHTML
- si la donnée était pas bonne, il regarde si son cache DATA (c'est a 
dire la donnée brute) est valide (si on a demandé un PDF avant, il aura 
deja regeneré le cache DATA, donc pas besoin de le refaire)
- si le cache DATA est bon, [1] on applique la feuille de style 
DATA->XHTML, on met a jour le cache et on va en [0]
- si le cache DATA n'est pas bon, on le recalcule, puis on renvient en [1]

*/

>  
>
>>- si les fichiers XLST qui n'existent pas, comment on gere les erreurs ? 
>>assertion ?
>>    
>>
>
>Ils existent ;)
>
>On a deux manières de fonctionner :
>
>- On utilise les assertions. Le problème se pose avec les feuilles de
>style incluses dans d'autres mais j'ai mon idée pour gérer ça : les
>abstractions de flux. Le module XSL utilise les streams PHP, il
>suffirait d'en créer un perso nommé xslt: qui ferait les assertions
>correctes. 
>Une assertion loupée génère une erreur HTTP 500, bête et méchante, c'est
>simple à gérer.
>L'utilisation de streams persos permet de faire des jolis trucs par la
>suite pour surcharger les XSLT (puisqu'on pourra faire de la génération
>du XSLT en fonction de paramètres si besoin est).
>
>- L'autre option est d'utiliser des gestionnaires d'erreur. Juste avant
>de lancer la transformation on lance un gestionnaire d'erreur PHP
>classique. Si il y a un problème pendant la transformation on récuperera
>la chose et on pourra éventuellement générer une exception.
>
>Les deux ne sont pas incompatibles d'ailleurs.
>  
>

pour l'instant, il n'y a pas d'inclusions de XSLT dans des XSLT, il me 
suffit donc de faire un file_exists('mon_xslt.xsl') ;

> 
>  
>
>>- pour les requetes SQL, comment on gere la sécurité sur les chaines ?
>>    
>>
>
>C'est à dire ?
>Tu dois toujours faire un échappement sqlite, même si théoriquement ta
>chaine ne contient rien de choquant. Faire ça de manière automatique
>sans chercher à savoir si le contenu vaut le coup évitera d'en oublier.
>  
>

donc si je fais un

SELECT pub FROM categories WHERE id='$id',

 je passe un coup de sqlite_escape_string() avant ?*
*

>
>  
>
>>- si je demande d'éditer une catégorie qui n'existe pas, je renvoit quel 
>>type d'erreur ?
>>    
>>
>
>Qu'entend tu par éditer ?
>  
>

$admin = new PluginAdminCategories ;
$admin->setID('MaCategorie') ;

si la catégorie MaCategorie n'existe pas, je renvoit quel type d'erreur 
? un FALSE, une exception ?

>  
>
>>- pour la création d'une nouvelle catégorie : newElement($id) : l'id est 
>>deja formaté comme y faut et on le verifie ou bien on envoit une chaine 
>>et on en déduit l'id puis on teste ?
>>    
>>
>
>Je n'aime pas les id ;)
>  
>
ce que j'appelle id, ca peut etre la chaine 'MaCategorie'

>mais tu peux essayer de faire un truc plus souple :
>$cat = new categorie ;
>$cat->setId($id)
>ou 
>$cat = new categorie ;
>$cat->setName($name) ;
>
>Et charge à ta classe d'aller récupérer ce qui lui manque en fonction de
>ce qu'elle a quand tu lui demande des infos.
>Ceci dit je parle là de théorie. Logiquement seul ton module devrait
>initialiser des catégories je pense, donc à toi de voir ce qui
>t'arrange.
>
>  
>

pour l'instant, pour éditer une catégorie existante, je fais :

$admin = new PluginAdminCategories ;
$admin->setID('MaCategorie') ;
// la ca récupere toute les infos de la catégorie 'MaCategorie'

Si je veux créer une nouvelle catégorie, je fais :
$admin = new PluginAdminCategories ;
$admin->newElement('MaCategorie') ;
/*
la ca construit une catégorie MaCategorie, en vérifiant qu'elle n'existe 
pas deja, et tout et tout (ca l'ajoute effectivement dans la base de 
donnée et dans le systeme de fichiers, pour pas qu'un autre malin créé 
la meme catégorie en meme temps ...)
*/

Ce que je voulais savoir, c'est si je passais une chaine qui 
représentait l'id voulu pour la nouvelle catégorie, ou bien une chaine a 
partir de laquelle on calcule un nouvel identifiant.

ensuite on fait des modifs :

$admin->setPub(time()) ;
...

puis on les applique :

$admin->Process() ;

voila ;-)

--
Grégoire Cachet - Développeur intégrateur chez Audacy

http://www.zwiffer.org           http://www.audacy.fr