BackBuilder v3

La version mineure de BackBuilder 3.6.0 est désormais disponible sur les branches du dépôt :
svn://svn.backbuilder.fr/backbuilder/branches/3.6.1

Elle regroupe les correctifs et évolutions appliqués jusqu'à la révision r666 du 7 février 2012.
Le détail est disponible dans le CHANGELOG associé : source:branches/3.6.1/CHANGELOG-3.6.1

ATTENTION
Cette version inclut la révision r647 pouvant avoir un impact sur les sites existants.
Elle corrige en effet, en vue d'améliorer les performances, un dysfonctionnement qui joignait automatiquement la table Contenu lors de l'ajout de la clause whereTypeContenuId() de la classe Page.

Désormais il est donc nécessaire de joindre spécifiquement la table Contenu lorsque le contenu XML est attendu :

Par exemple :

1 $liste= PageTable::getInstance() ->selectList()
2         ->setHydrateMode(LpDb::HYDRATE_ARRAY_HIERARCHY)
3  /*=>*/ ->withContenuRoot()    // => Cette instruction est désormais nécessaire pour obtenir le XML
4         ->whereTypeContenuId(TC_ARTICLE)     
5         ->getQuery()
6         ->getHydratedAll(); 

La version mineure de BackBuilder 3.6.0 est désormais disponible sur les branches du dépôt :
svn://svn.backbuilder.fr/backbuilder/branches/3.6.0

Elle regroupe les correctifs et évolutions appliqués jusqu'à la révision r641 du 29 décembre 2011.
Le détail est disponible dans le CHANGELOG associé : source:branches/3.6.0/CHANGELOG-3.6.0

Trois nouveaux modifier Smarty ont été introduits dans la révision r654 de BackBuilder 3.7
Ces modifier simplifient la manipulation des liens dans les templates :

getUrl

Le modifier getUrl retourne l'url associée à un lien BackBuilder. Il peut être appelé directement sur la variable smarty injectée par BackBuilder dans le template et ne nécessite pas l'utilisation d'un tableau.
Avant il était nécessaire de travailler directement sur le tableau retourné par BakBuilder :

1 <a href="{$lien.url}">Texte du lien</a>

Désormais la méthode suivante, plus propre, peut être utilisée :

1 <a href="{$lien|getUrl}">Texte du lien</a>

getLink

L'avantage des nouveaux modifier est surtout visible grâce au modifier getLink. Le modifier getLink retourne un lien complet.
Avant (manipulation du tableau retourné par BakBuilder) :

1 <a href="{$lien.url}" title="{$lien.title}" {if $lien.popup}target="_blank"{/if}>{$lien.title}</a>

Désormais la méthode suivante, plus propre, peut être utilisée (et retourne le même résultat):

1 {$lien|getLink}

Plusieurs paramètres peuvent être passés au modifier pour ajouter ou forcer certains attributs :

1 {$lien|getLink:"myClass":"myIdForTheLink":"Texte du lien":"Titre du lien"}

wrapLink

Le modifier getLink est très pratique mais il n'est pas idéal pour créer un lien autour d'une image. C'est pourquoi le modifier wrapLink existe. Il encadre l'élément sur lequel il est appliqué par un lien :

Avant (manipulation du tableau retourné par BakBuilder) :

1 <a href="{$lien.url}" title="{$lien.title}" {if $lien.popup}target="_blank"{/if}>{$image|getFile}</a>

Désormais les modifier peuvent être chaînés (le lien doit alors être passé en premier paramètre du modifier) :

1 {$image|getFile|wrapLink:$lien}

getLinkAttributes

Il est également possible de récupérer uniquement les attributs du lien. Cela peut s'avérer très utile pour construire des liens personnalisés.

Exemple :

1 <a href="{$link|getUrl}" {$link|getLinkAttributes}>
2     <span class="btnLink">$link.title</span>
3     <p class="description">Lorem ipsum dolor sit amet</p>
4 </a>

Depuis la révision r653 (BackBuilder v3.7), il est désormais possible d’interagir de façon globale sur toutes les instances Smarty et donc d'assigner des variables qui seront disponibles dans tous les smarty des contenus BackBuilder.
Pour cela un nouvel événement a été créé dans la classe LpSmarty : "lpsmarty.do_before_fetch". Cet évènement est déclenché juste avant que la fonction $smarty->fetch() soit lancée. Il est donc possible à cet instant d'interagir sur toutes les variables assignées à l'instance smarty pour en ajouter, en modifier ou en supprimer.

Voici un exemple qui initialise un tableau de pages spéciales qui peuvent être appelées par n'importe quel template pour créer des liens. Le bloc de code suivant est ajouté dans le fichier index.php du site :

 1 BackBuilder::getInstance()->getEventDispatcher()->connect('lpsmarty.do_before_fetch', function (sfEvent $e){
 2     $specialPages = PageTable::getInstance()->selectList()
 3                 ->isOnline()
 4                 ->ofVersionId(BackBuilder::getInstance()->getVersion()->_ID)
 5                 ->whereTypeContenuIds(array(TCROOT_LOGIN, TCROOT_HOME))
 6                 ->getQuery()
 7                 ->orderBy("DATE DESC")
 8                 ->groupBy("TypeContenuID")
 9                 ->getHydratedAll(null, LpDb::HYDRATE_OBJECT, "TypeContenuID");
10     $e->getSubject()->assign("specialPages", $specialPages);
11 });

Le tableau de pages spéciales est ensuite accessible dans n'importe quel template smarty pour créer un lien vers la page de login par exemple :

1 <a href="{$specialPages[$smarty.const.TCROOT_LOGIN]->_urlRewriting}">Login</a>

Attention cependant, dans notre exemple, la requête va être effectuée à chaque appel de template. Ceci n'est pas une bonne pratique car cette requête est assez gourmande. Il est donc recommandé d'utiliser un singleton pour que la requête ne soit effectuée qu'une seule fois par page, ou mieux, de passer par un système de cache :

 1 BackBuilder::getInstance()->getEventDispatcher()->connect('lpsmarty.do_before_fetch', function (sfEvent $e){
 2     if(!$specialPages = apc_fetch("special_pages")){
 3         $specialPages = PageTable::getInstance()->selectList()
 4                     ->isOnline()
 5                     ->ofVersionId(BackBuilder::getInstance()->getVersion()->_ID)
 6                     ->whereTypeContenuIds(array(TCROOT_LOGIN, TCROOT_HOME))
 7                     ->getQuery()
 8                     ->orderBy("DATE DESC")
 9                     ->groupBy("TypeContenuID")
10                     ->getHydratedAll(null, LpDb::HYDRATE_OBJECT, "TypeContenuID");
11         apc_add("special_pages", $specialPages);
12     }
13     $e->getSubject()->assign("specialPages", $specialPages);
14 });

Une nouvelle branche 3.7 de BackBuilder a été initiée.
Elle est disponible sur SVN : svn://svn.backbuilder.fr/backbuilder/branches/3.7

Cette version est encore en ALPHA. Elle est déconseillée pour un usage en production.

La première grande nouveauté de cette version est la migration vers Smarty 3. Dans le cadre de cette version, la classe SmartyBC est utilisée, ce qui assure une rétro compatibilité quasi entière avec l'ancienne version de Smarty. Les impacts sur les sites sont donc mineurs.

Accès au singleton BackBuilder depuis un template facilité¶

Grâce à Smarty 3, il est désormais possible de chaîner des requêtes. Les objets de la classe BackBuilder deviennent ainsi beaucoup plus accessibles. Il devient par exemple possible de récupérer un code pays directement depuis le template :

1 Code pays : {BackBuilder::getInstance()->getVersion()->getLangage()->_codePays}

Inclusion de blocs dynamiques : Mécanisme de render¶

Un nouveau système d'inclusion a été intégré à BackBuilder.
Il permet d'inclure dans un template un sous-template disposant de son propre fichier PHP. Ainsi, le code suivant inclut dans le template courant le fichier include/header.tpl après avoir executé le fichier include/header.php

Fichier template incluant un header :

 1 <html>
 2   <body>
 3     <div class="header">
 4       {render template="include/header.tpl"}
 5     </div>
 6     <div class="content">
 7       {$content}
 8     </div>
 9   </body>
10 </html>

Fichier template du header (include/header.tpl) :

 1 {foreach $tree as $rub}
 2   <li id="mainNavBtn{$rub@iteration|string_format:"%02d"}">
 3     <a href="rubrique.php?Id={$rub.ID}"><span>{$rub.nom}</span></a>
 4     <ul>
 5       {foreach $rub['childrens'] as $ssRub}
 6         {if $ssRub.TypeRubriqueID != $smarty.const.TRUB_QUIZ}
 7           <li><a href="rubrique.php?Id={$ssRub.ID}">{$ssRub.nom}</a></li>
 8         {/if}
 9       {/foreach}
10     </ul>
11   </li>
12 {/foreach}

Fichier php executé avant l'inclusion du header (include/header.php) :

1 $tree = BackBuilder::getInstance()->getVersion()->getRubrique()
2         ->getDescendantsQuery(2)
3         ->andWhere(RubriqueTable::getInstance()->getAlias().".visible = 1")
4         ->getHydratedAll(null, LpDb::HYDRATE_ARRAY_HIERARCHY);
5 
6 $smarty->assign(array(
7     "tree" => $tree
8 ));

La révision r638 intègre une gestion de l'import / export de portion de l'arborescence. Ces fonctionnalités sont accessibles en effectuant un clic droit sur les rubriques de l'arborescence.

De nouvelles fonctions ont également été implémentées sur la classe Contenu :

 1 
 2 class Contenu extends LpDbRecord {
 3     /**
 4      * Retourne les identifiants de média pour un élément du contenu
 5      * @param type $elementId Identifiant de l'élément dont on souhaite récupérer les médias
 6      * @return array Liste d'identifiants de médias
 7      */
 8     public function getMediasIdsForElementId($elementId){}
 9 
10     /**
11      * Retourne les médias pour un élément du contenu
12      * @param type $elementId Identifiant de l'élément dont on souhaite récupérer les médias
13      * @return array Liste d'identifiants de médias
14      */
15     public function getMediasForElementId($elementId){}
16 
17     /**
18      * Retourne les médias associés à un contenu en s'appuyant sur les tags "media" du type de contenu
19      * @return array Liste d'identifiants de médias
20      */
21     public function getMediasIds(){}
22 
23     /**
24      * Retourne les médias associés à un contenu en s'appuyant sur les tags "media" du type de contenu
25      * @return array Liste de médias
26      */
27     public function getMedias(){}
28 }

Dans le cadre des révisions r634, r635 et r636, intégrant la possibilité d'importer une rubrique dans l'arborescence, 2 méthodes du noyau ont été renommées.
Le fonctionnement des méthodes est exactement le même et il ne devrait pas y avoir de régression sur les sites Internet déjà développés sur la 3.6 s'ils n'utilisent pas ces méthodes.
Par mesure de sécurité, il est conseillé d'effectuer une recherche sur le nom des méthodes dans les projets que vous mettez à jour afin de s'assurer que vous n'utilisez pas l'ancienne méthode.

• Contenu::getContenuEnfantsIds() devient Contenu::getEnfantContenusIdsFromXml()
• Contenu::getContenuEnfants() devient Contenu::getEnfantContenusFromXml()

Cette modification a été faite dans un souci d'homogénéisation avec les autres méthodes de la classe Contenu (préfixage par getEnfant) et pour clarifier la différence avec les méthodes Contenu::getEnfantContenus() et Contenu::getEnfantContenusIds() qui récupèrent les enfants à partir de la table de liaison ContenuContenu.

Il est désormais possible d'associer des options de contribution aux éléments <liens> d'un type de contenu.

Ces options peuvent être de quatre types :

• textbox
• select (simple uniquement)
• checkbox
• radio

Le schéma XML des types de contenu a été modifié en conséquence

Exemple de déclaration dans un type de contenu :

 1     <liens id="remontee">
 2         <label>Sélection de lien</label>
 3         <options>
 4             <option id="linkTypeSelect" type="select">
 5                 <label>Type (Select) : </label>
 6                 <items>
 7                     <item>    
 8                         <value>none</value>
 9                         <label />
10                     </item>
11                     <item>    
12                         <value>1</value>
13                         <label>Dossier</label>
14                     </item>
15                     <item>    
16                         <value>2</value>
17                         <label>Blog</label>
18                     </item>
19                 </items>
20             </option>
21             <option id="linkTypeRadio" type="radio">
22                 <label>Type (Radio) : </label>
23                 <items>
24                     <item>    
25                         <value>1</value>
26                         <label>Dossier</label>
27                     </item>
28                     <item>    
29                         <value>2</value>
30                         <label>Blog</label>
31                     </item>
32                 </items>
33             </option>
34             <option id="state" type="checkbox">
35                 <label>Visible : </label>
36                 <value>1</value>
37             </option>
38             <option id="text" type="text">
39                 <label>Sous-titre : </label>
40                 <value>Texte par défaut</value>
41             </option>
42         </options>
43     </liens>

La méthode TypeContenu::linkToArray() permet ensuite d'obtenir les éventuelles options contribuées sous forme de tableau associatif, pour l'exemple ci-dessus :

remontee: {
   value   : "page.php?ID=390776",
   url     : "page.php?ID=390776",
   popup   : 0,
   title   : "Titre du lien",
   type    : "page",
   id      : 390776,
   options : {
      linkTypeSelect : 1,
      linkTypeRadio  : 1,
      state          : 1,
      text           : "Sous-titre" 
   }
}

Un nouveau tutorial a été mis en ligne sur le wiki. Il présente le singleton LpRequest, introduit dans la version 3.6 de BackBuilder et qu'il est recommandé d'utiliser en remplacement de $_GET[], $_POST[] et $_REQUEST[].

De nombreuses fonctionnalités de filtrage ont été introduites dans la relase r606 de la version 3.6

Le bug #8922 nous a offert l'occasion de réorganiser la gestion des exceptions du back-office.

Au préalable, il était recommandé d'enchaîner chaque appel Ajax par un traitement d'erreur comme ceci :

1 $.post(PATH_ADMIN+"langage/services/newLangage.php", langage, callback).error(bb.utils.ajaxErrorHandler);;

Désormais, ceci n'est plus utile. En effet, le traitement des erreurs ajax a été ajouté aux traitements par défaut effectués par jQuery.
Le code suivant a donc été introduit et permet un traitement par défaut des 3 principaux types d'erreurs :

1. Erreur 403 : Redirection vers une page de connexion
2. Erreur 500 : Affichage de l'exception
3. Erreur 404 : Affichage d'une erreur informant que le script n'a pas été trouvé

Voici le code résultant :

 1 initAjax: function(){
 2     $.ajaxSetup({
 3         error: function(jqXHR, textStatus, errorThrown){
 4             switch(jqXHR.status){
 5                 case 403:
 6                     window.location = PATH_ADMIN+"connexion.php";
 7                     break;
 8                 case 500:
 9                     bb.utils.ajaxErrorHandler(jqXHR, textStatus, errorThrown);
10                     break;
11                 case 404:
12                     bb.utils.dialog("L'appel Ajax a échoué car le script demandé est introuvable");
13                     break;
14             }
15         }
16     });
17 }

Nous en avons profité pour mettre à jour la documentation sur la gestion des Exceptions Lp :
http://forge.backbuilder.fr/projects/back-builder-v3/wiki/LpException