Voici une astuce publiée sur le forum de CodeIgniter qui permet de définir le timezone à utiliser par la base de données un seule fois pour tous les modèles de l’application.

Pour réaliser cette tâche, l’auteur à simplement dérivé la classe Model de CodeIgniter afin d’exécuter la requête SQL modifiant le timezone à la construction de l’objet. Ainsi, comme lorsqu’on utilise ACICRUD, les modèles de l’application doivent étendre la classe mère au lieu de la classe Model.

Voici l’exemple de code proposé par flaky :

class Master_model extends Model{
    public function __construct(){
        parent::__construct();
 
        $this->set_timezone();
    }
 
    public function set_timezone(){
        $this->db->query("SET time_zone='+0:00'");
    }
}
 
class Some_model extends Master_model{
    public function __construct(){
        parent::__construct();
    }
}

Voir le post original.

MongoDB est un gestionnaire de base de données « NoSQL » orientée documents dans la lignée de CouchDB et Riak. Ces SGBD dits SchemaLess permettent de stocker des objets dynamiques sous forme de Hash (notamment au format JSON) indépendamment de leur structure. Il n’existe donc plus de contraintes d’évolution de tables comme c’est le cas par exemple avec MySQL.

Ainsi, la mise à jour des objets peut être effectuée dynamiquement (ajouts de champs par exemple) sans impacts sur le stockage de ceux-ci.

MongoDB (qui est écrite en C++) a pour avantages d’être Open Source et de présenter de très bonnes performances.

Si vous désirez intégrer MongoDB à vos applications CodeIgniter, sachez qu’il existe déjà plusieurs ressources et librairies facilitant cette tâche !

• CodeIgniter Mongo Library
• Tutoriel MongoDB + CodeIgniter
• Thread sur StackOverflow

Bonne intégration !

La problématique

Lorsque des animations Flash (SWF) utilisent des fichiers XML pour afficher du contenu dynamique et que ce même fichier XML est généré dynamiquement, il est classique que certains navigateurs gardent en cache l’un ou l’autre et n’affichent pas les modifications de contenu en temps réel.

Ce mécanisme de cache est tout à fait classique sur le web, en revanche il peut devenir problématique si les utilisateurs d’un Backoffice (par exemple) ne peuvent pas voir le rendu final de leurs modifications sans vider leur cache, surtout s’ils sont néophytes.

Heureusement il existe une directive Apache permettant d’interdire la mise en cache de certains types de fichiers. Cette détection, basée sur l’extension du fichier vas permettre d’envoyer des instructions (headers) au navigateur interdisant la mise en cache soit du fichier swf, soit du fichier xml, soit des deux. Ainsi, à chaque rafraichissement de la page, les deux fichiers seront re-téléchargés par le client.

Ce mécanisme garantit donc que les modifications du contenu de l’animation Flash sera systématiquement visible par le client.

Mise en place du code dans un fichier .htaccess

Les instructions Apache sont à placer dans un fichier .htaccess à la racine de votre serveur web. Vous pouvez ajouter ou supprimer des extensions à votre convenance, veillez simplement à les séparer par le caractère « |« .

Si vous n’avez pas de fichier htaccess à la racine de votre FTP, créez simplement un fichier nommé .htaccess à l’aide d’un éditeur de texte, puis transférez le via un logiciel FTP.

Voici le code à placer dans votre fichier

<FilesMatch "\.(swf|xml)$">
 ExpiresDefault A0
 Header set Cache-Control "no-store, no-cache, must-revalidate, max-age=0"
 Header set Pragma "no-cache"
</FilesMatch>

Le contexte

Imaginons que vous devez appliquer le même comportement d’événement à un ensemble d’éléments, il devient alors tout à fait naturel de créer une classe CSS qui permettra d’identifier tous les éléments et ainsi leur appliquer le comportement d’événement simultanément.

Ceci ce traduirait par le code jQuery ci-dessous (notez que j’utilise jQuery à la place de $ pour des questions de compatibilité avec d’autres librairies) :

jQuery('.jQuery-elements-1').change(function(e){
   //traitement de l'événement
});

Le problème

Le code que nous venons de voir fonctionne bien, en revanche comment appliquer ce même comportement à un second ensemble d’éléments sans pour autant dupliquer de code ? Imaginons maintenant que nous possédons un second ensemble d’éléments portant pour une raison quelconque une classe CSS différente mais pour lequel nous désirons le même comportement d’événement.

La première solution qui vient à l’esprit consiste à dupliquer le code précédemment vu et à modifier la classe CSS utilisée pour pointer les éléments. C’est là qu’un peu d’astuce vas nous permettre d’éviter cette dupplication ! En effet, jQuery possède un puissant système de sélecteurs permettant de cibler des éléments HTML,en l’occurrence il suffira de séparer les deux classes CSS par une virgule pour appliquer le comportement d’événements à tous les éléments d’un seul coup !

jQuery('.jQuery-elements-1, .jQuery-elements-2').change(function(e){
   //traitement de l'événement
});

Pratique, n’est-ce pas ?

L’erreur fatale PHP Cannot create references to elements of a temporary array expression survient par exemple lorsqu’on tente d’assigner une variable par référence au sein d’une boucle foreach alors que le tableau d’entrée est une variable temporaire, c’est à dire générée et interprétée au sein de l’instruction foreach.

La variable n’ayant pas été déclarée et initialisée en dehors de la boucle, l’accès aux références de chaque élément n’est donc pas possible.

Le code ci-dessous illustre un cas de figure où l’erreur survient, notez que les méthodes utilisées sont celles de la classes Active Record du framework CodeIgniter :

$q = $this->o_db->get();
 
// The foreach's source array is created inside the foreach
// This way cause the fatal error "Cannot create references to elements of a temporary array expression"
foreach($q->result() as &$row) {
 
    $row->some_property = 'some_value';
 
}

La solution

Il suffit de déclarer le tableau d’entrée de la boucle foreach à l’extérieur de celui-ci :

$q = $this->o_db->get();
 
$result = $q->result();
 
// The foreach's source array is created outside the foreach
// This way allows to assign $row by reference
 
foreach($result as &$row) {
 
    $row->some_property = 'some_value';
 
}

La version 1.3.x de Magento comporte des dysfonctionnements sous Internet Explorer ou encore Safari 4 sur certains serveurs tels que :

• L’impossibilité de se connecter à l’interface d’administration
• L’impossibilité d’ajouter un produit au panier

Il existe plusieurs solutions permettant de corriger ces problèmes, en voici une qui fonctionne dans certains cas et consiste à réduire le niveau de sécurité de Magento concernant les cookies.

Rendez-vous dans Système / Configuration / Web et appliquez les réglages visibles sur la capture d’écran ci-dessous :

Remplacez Domaine du cookie par votre nom de domaine (ex : www.kromack.com).

Corriger le bug de double quantité lors de l’ajout au panier

Il est possible que vous obteniez également un nouveau bug qui double systématiquement la quantité sélectionnée par l’utilisateur lors de l’ajout d’un produit au panier.

Pour corriger ce bug, ouvrez le fichier template/catalog/product/view/addtocart.phtml et remplacez à la ligne 37 :

<button type="button" class="form-button" onclick="productAddToCartForm.submit()">

Par :

<button type="button" class="form-button" onclick="productAddToCartForm.submit(); return false;">

N’oubliez de raffraichir le cache de Magento pour prendre en compte ces changements.

Tutoriel ACICRUD #5

Dans ce cinquième tutoriel d’utilisation de la librairie ACICURD pour CodeIgniter, nous allons voir comment définir de nouvelles méthodes dans les modèles utilisant ACICRUD et comment profiter de certaines méthodes de la librairie.

Création d’une méthode spécifique

Imaginons que vous désiriez sélectionner un champ username dans une table user à partir de l’identifiant de l’utilisateur id. Nous allons pour cela ajouter une nouvelle méthode dans notre modèle ayant exactement le fonctionnement que nous désirons et s’appuyant sur la méthode $this->row() qui exécute la requête Active Record et retourne un objet résultat.

Notez qu’il serait également possible d’utiliser la méthode getAll() d’ACICRUD pour arriver à ce résultat.

Voici le code du fichier user.php à placer dans le répertoire models :

<?php
 
class User extends Acicrud {
 
	//CONSTRUCTOR
	public function __construct()
	{
		parent::__construct('user');
	}
 
	//CUSTOM METHODS
 
	/**
	 * Return the username of an user identified by his id
	 *
	 * @param int $id
	 * @return Object
	 */
	public function get_username($id = null) {
 
		try {
 
			// Checking if $id is a valid primary key value
			$this->checkId($id);
 
			// Building the query
			$this->db->select('username')->from($this->table)->where($this->key, $id);
 
			// Returning the result
			return $this->row();		
 
		} catch(Exception $e) {
 
			throw($e); // Throws the ACICRUD's exception
 
		}
	}
 
}
 
?>

Il vous est donc tout à fait possible d’ajouter vos propres comportements au sein d’un modèle héritant de la librairie ACICRUD. Notez que dans cet exemple, la méthode s’appuie également sur le système d’exceptions géré par ACICRUD. Je vous conseille donc d’inclure l’appel de la méthode get_username dans votre contrôleur au sein d’un bloc try/catch.

Tutoriel suivant

» Utiliser plusieurs bases de données

Nous l’attendions depuis longtemps ! La forge du framework JavaScript MooTools destinée au partage de plugins est désormais en ligne !

Celle-ci concentre déjà plusieurs dizaines de plugins et propose pour chacun d’entre eux le téléchargement des sources, une démonstration, un tutoriel et la liste des dépendances, chose qui manquait cruellement par le passé.

Pour les utilisateurs de jQuery, la forge de MooTools est comparable à la section plugins du site de jQuery.

Une petite sélection de plugins incontournables

Voici une petite sélection personnelle des meilleurs plugins actuellement disponibles sur la forge :

• LazyLoad
• MooTools FileManager
• Lighter
• ScrollSpy
• InputMask
• MeioMask
• Database

Accéder à la MooTool Forge.

Je vous propose au travers de ce tutoriel de mettre en évidence 3 bonnes pratiques concernant la gestion de base de données sous CodeIgniter et plus particulièrement par rapport à la création de modèles basés sur la classe Active Record.

Je précise avant tout que les points évoqués ci-après sont pleinement compatibles avec ACICRUD, ma librairie d’abstraction de modèles pour CodeIgniter.

Gérer efficacement les préfixes de tables

Afin de débuter cet article, parlons des préfixes de tables pour vos applications. Puisqu’il est admit par le simple fait d’utiliser une librairie d’abstraction de base de données comme Active Record sous CodeIgniter, que votre base de données est abstraite, c’est à dire que l’on ne connaît pas en théorie quel système de gestion de base de données est utilisé en production, je considère également admit que vous ne devriez pas connaître la liste des tables présentes dans la base de données de production (ou du moins qu’il ne faut pas en tenir compte lors de la création du schéma de base de données de votre application).

Ainsi, afin d’éviter toute collision de table avec un autre système utilisant la même base de données, il devient très utile de préfixer l’ensemble des tables de notre application par une chaîne unique mais explicite.

Pour illustrer ceci, nous allons partir du principe que nous concevons une application nommée « Gestion » pour un client donné. Nous ne pouvons pas connaître à l’avance la liste des tables dans la base de données qu’utilise déjà notre client pour ses autres applications.

Aussi, afin d’éviter toute collision sur les noms de tables, nous allons choisir de préfixer nos tables avec la chaîne « gestion_ ».

C’est ainsi que toutes nos tables SQL devront être créées avec ce préfixe, comme par exemple « gestion_user », « gestion_user_acl », etc. De cette manière, si la base de données de production comporte déjà une table nommée « user », cela ne générera aucun conflit.

Ceci est très facilement gérable avec CodeIgniter, en effet il suffit d’indiquer le préfixe de table à utiliser dans le fichier de configuration database.php. Ainsi, Active Record utilisera automatiquement le préfixe de nos tables pour lors de la génération de requêtes SQL.

$db['production']['hostname'] = "localhost";
$db['production']['username'] = "root";
$db['production']['password'] = "password";
$db['production']['database'] = "the_production_database";
$db['production']['dbdriver'] = "mysql";
$db['production']['dbprefix'] = "gestion_";
$db['production']['pconnect'] = FALSE;
$db['production']['db_debug'] = FALSE;
$db['production']['cache_on'] = FALSE;
$db['production']['cachedir'] = "";
$db['production']['char_set'] = "utf8";
$db['production']['dbcollat'] = "utf8_general_ci";

Ne pas coder en dur les noms de table !

Voici une règle simple mais souvent oubliée : éviter de coder en dur. Ceci est particulièrement valable pour les noms de tables !

Voici comment profiter simplement de la programmation orientée objet afin de transformer notre nom de table en attribut de classe de notre modèle.

<?php
 
class User extends Model {
 
    public $table = 'user';
 
    public function __construct()
    {
        parent::__construct();
 
    }
 
    public function example() {
 
    	//$this->table is used instead of the 'user' string.
        //Active Record will use `gestion_user`
    	$this->db->select()->from($this->table);
 
    	$query = $this->db->get();
 
    	return $query->result();
 
    }
 
}
 
?>

Ainsi, à chaque fois que nous aurons besoin d’appeler la table utilisée par le modèle, il suffira d’utiliser $this->table, ce qui aura également comme avantage de rendre les méthodes du modèle plus génériques.

Utiliser un préfixe de table avec la classe Database

Il existe certains cas de figures ou les méthodes évoquées ci-dessus ne suffisent pas totalement. C’est notamment le cas lorsqu’une requête SQL doit être effectuée sur plusieurs tables ou lorsque le query builder d’Active Record n’est plus utilisé.

Prenons un exemple concret en sélectionnant des données dans la table gestion_user via la méthode query(). Dans ce cas précis, le préfixe de table ne sera pas automatiquement ajouté par CodeIgniter puisque query() permet justement d’écrire manuellement une requête SQL.

Il faut alors utiliser $this->db->dbprefix() afin de générer le préfixe de table adéquat.

<?php
 
class User extends Model {
 
    public $table = 'user';
 
    public function __construct()
    {
        parent::__construct();
 
    }
 
    public function manuel_query() {
 
    	//One way
    	$query = $this->db->query('SELECT * FROM `' . $this->db->dbprefix($this->table) . '` LIMIT 0 , 30');
 
    	//Second way
    	$query = $this->db->query('SELECT * FROM `' . $this->db->dbprefix . $this->table . '` LIMIT 0 , 30');
    }
 
}
 
?>

Notez que les deux méthodes produisent un résultat identique.

Conclusion

Il existe de nombreuses méthodes permettant d’améliorer la qualité et la généricité des modèles sous CodeIgniter, et nous n’abordons même pas les notions d’ORM ou de CRUD dans cet article. Quoiqu’il en soit, je suis sûr que chaque développeur CodeIgniter utilise ses propres techniques, aussi n’hésitez pas à partager les vôtres en commentant ce billet