Circum Blog

Circum Net – IT – Conseils pratiques

SQLite: récupération d’un résultat dans un objet spécifique

PHP, SQLite

La méthode setFetchMode de la librairie PDO permet de récupérer, dans un objet spécifique, une ligne résultat d’une requête SQL (SELECT).

En fixant le premier argument de cette méthode à PDO::FETCH_CLASS et en lui fournissant le nom d’une classe (définie préalablement), c’est cette dernière qui va être invoquée et ses propriétés vont être affectées avec les valeurs des champs correspondant (le constructeur est également appelé). Voici un code fonctionnel qui illustre cela.

PDO::FETCH_CLASS

<?php
class Movie
    {
    public $title;
    public $director;
    public $description;
    public $year;

    // Les propriétés de l'objet sont fixées par PDO avant l'appel au constructeur
    // Le constructeur peut ensuite prendre le relais et intervenir sur les propriétés
    function __construct()
        {
        $this->title = strtoupper($this->title);
        }
    }

try
    {
    $dbh = new PDO('sqlite:./movies');

    $sql = 'SELECT * FROM movies';
    $stmt = $dbh->query($sql);

    // Retourne une nouvelle instance de la classe demandée
    // Le mapping est fait entre les champs et les propriétés
    $stmt->setFetchMode(PDO::FETCH_CLASS, 'Movie');

    while($obj = $stmt->fetch())
        {
        echo $obj->title . ' - ' . $obj->director . PHP_EOL;
        }

    }
catch(PDOException $e)
    {
    echo $e->getMessage();
    }
?>


PHP et son serveur web interne

PHP

Depuis sa version 5.4.0, la distribution de PHP fournit un serveur web interne.

L’aspect pratique de cette initiative réside dans le fait de disposer d’un serveur HTTP intégré au langage et donc capable de vous faire bénéficier d’un cadre de développement web sans configuration particulière ni package envahissant.
Cet outil supplémentaire est cependant limité en terme de fonctionnalités et n’est pas prévu pour la mise en production d’une application. Il n’est à envisager que dans la cadre de tests, de prototypage, d’apprentissage ou de démonstration

Pour démarrer le serveur intégré, il suffit -dans un fenêtre terminal- d’exécuter la ligne de commande suivante à la racine de votre projet :

php -S localhost:8000

Le serveur web sera alors lancé et attendra les requêtes HTTP sur l’adresse IP et le port qui lui ont été passés en argument.

Pour le tester, vous pouvez saisir l’URL http://localhost:8080 dans la barre d’adresse d’un navigateur web.



MySQL et le fichier journal

Bases de données, MySQL

Démarré avec le paramètre ‘–log-bin[=file_name]’, le serveur mysql enregistre dans un fichier de logs (fichier journal) toutes le commandes SQL ayant donné lieu à des modifications de données.

L’intérêt d’un tel fichier, dans le cadre d’une politique de backup du serveur, est de pouvoir plus facilement récupérer les dernières opérations sur les données en cas d’arrêt brutal du système (coupure d’alimentation, plantage du système, etc.). Il constituera la source pour la ré-exécution des requêtes qui ont eu lieu après la dernière sauvegarde.

Lancement via la ligne de commande :

> bin\mysqld-nt –log-bin standalone

L’activation du système de logging peut également être réalisée via le fichier de configuration du serveur (my.ini ou my.cnf) en y ajoutant –sous la rubrique [mysqld]- la clause suivante :

set-variable=log-bin=[dir_path]

exemple :

set-variable=log-bin=c:/mysql/data

Si aucun nom de fichier n’est précisé en argument alors le système utilise et stocke les informations dans un fichier portant le nom de la machine hôte suivi du suffixe ‘-bin’. Le répertoire par défaut pour l’écriture de ce fichier est le répertoire de données du serveur (‘data’ ou ‘var’).

Il est possible d’analyser le contenu du fichier de logs avec l’utilitaire ‘mysqlbinlog’ qui se trouve dans le répertoire ‘bin’ de votre installation.

> bin\mysqlbinlog E:\dbdata\mysql\GRD-Laptop-bin.001

Pour rafraîchir, sauvegarder et remettre à zéro les fichiers de logs, il faut utiliser l’exécutable ‘mysqladmin’.

> bin\mysqladmin flush-logs



Passage en majuscules/minuscules

XSLT

En XSLT 1.0, il n’est pas possible de faire directement appel à une fonction du style uppercase() ou lowercase() pour assurer le passage en majuscules (ou minuscules) d’une chaîne de caractères. Il faut se trourner vers l’instruction translate().

Exemple en XSLT 1.0 :

<?xml version="1.0" encoding="ISO-8859-1"?>
<xsl:stylesheet version="1.0">

<xsl:variable name="lowercase" select="'abcdefghijklmnopqrstuvwxyz'" />
<xsl:variable name="uppercase" select="'ABCDEFGHIJKLMNOPQRSTUVWXYZ'" />

<xsl:template match="/">
  <xsl:value-of select="translate(title, $lowercase, $uppercase)" />
  <xsl:value-of select="translate(reference, $uppercase, $lowercase)" />
</xsl:template>

</xsl:stylesheet>

En XSLT 2.0 par contre, on dispose des fonctions “upper-case” et “lower-case”. Ce qui facilite la tâche.

Exemple en XSLT 2.0:

<?xml version="1.0" encoding="ISO-8859-1"?>
<xsl:stylesheet version="2.0">

<xsl:variable name="lowercase" select="'abcdefghijklmnopqrstuvwxyz'" />
<xsl:variable name="uppercase" select="'ABCDEFGHIJKLMNOPQRSTUVWXYZ'" />

<xsl:template match="/">
  <xsl:value-of select="upper-case(title)" />
  <xsl:value-of select="lower-case(reference)" />
</xsl:template>

</xsl:stylesheet>


Requête multi-bases de données

Bases de données, MySQL

En MySQL, il est tout-à-fait possible de mettre en relation (jointure) plusieurs bases de données afin de répondre à une requête d’information.

Pour réaliser cela, rappelons d’abord qu’une jointure se fait en imposant l’égalité des valeurs d’une colonne d’une table à une colonne d’une autre table. Dans notre cas, il suffira d’indiquer clairement au compilateur la provenance de chacune des colonnes concernées par la mise en relation. Ainsi, chaque colonne devra être précédée du nom de la base de données (suivi d’un point) et du nom de la table (suivi d’un point).

db_name.table.name.column_name

Exemple d’une requête multi-bases

SELECT db1.clients.nom, db1.clients.adresse, db2.membres.statut
FROM db1.clients, db2.membres
WHERE db2.membres.cotisation IS ‘OK’ AND db1.clients.id = db2.membres.id


PHP DOM – Validation d’un document XML

Uncategorized

En PHP, à travers l’API DOM, il est possible de vérifier la validité d’un document XML par rapport à une DTD. On utilise pour cela la méthode ‘validate’ de l’objet ‘DOMDocument’.

<?php
$dom = new DOMDocument;
$dom->Load('biblio.xml');
if ($dom->validate())
    {
    echo "Ce document est valide !\n";
    }
?>

On peut intégrer, suite à la validation, la gestion des éventuels messages d’erreur comme illustré dans le code qui suit :

<?php
$dom = new DOMDocument;
$dom->load('biblio.xml');
libxml_use_internal_errors(true);
if ($dom->validate())
    {
    echo 'Ce document est valide !';
    }
else
    {
    echo 'Document non valide:';
    $errors = libxml_get_errors();
    foreach ($errors as $error)
    {
    echo 'message: ('.$error->code.') '.$error->message.'';
    echo 'ligne: ' . $error->line . '';
    }
}
?>

Il est également possible de pousser plus avant la phase de validation en ayant recours non plus aux DTD mais aux schémas XML. Ceux-ci, définis par le W3C comme une alternative aux DTD, sont écrits en XML et permettent de préciser un ensemble de définitions et de contraintes appliquables aussi bien sur le contenu que sur la structure même d’un document XML.

On utilise pour ce type de validation la méthode ‘schemaValidate’ de l’objet ‘DOMDocument’.

<?php
$dom = new DOMDocument;
$dom->Load('biblio.xml');
if ($dom->schemaValidate('biblio.xsd'))
    {
    echo "Ce document est valide !\n";
    }
?>


L’approche MVC

Programmation

L’approche MVC, pour Model-View-Controler ou en français Modèle-Vue-Contrôleur, privilégie la séparation du traitement des données de leur présentation. Elle préconise l’organisation du code d’interface utilisateur en trois composants distincts :

  • Modèle : en charge de la gestion des données d’une application (partie logique de l’application / règles métiers).
  • Vue : en charge du dialogue avec les utilisateurs (partie habillage de l’application / dessin des écrans).
  • Contrôleur : en charge de l’orchestration des requêtes des utilisateurs et de leur relais vers les modèles (partie liaison modèles-vues / aiguillage).

Cette approche permet aux développeurs de profiter des avantages suivants :

– séparation entre les données, la présentation et les traitements;
– souplesse;
– maintenance allégée;
– possibilité d’évolution renforcée;
– spécialisation des tâches et division claire du travail.

Architecture MVC

Architecture MVC - 3 niveaux

Le contrôleur

Le contrôleur n’effectue pas ou très peu de traitement (éventuellement un travail de préparation et/ou de redirection). Il réceptionne et gère les événements provenant de l’utilisateur, enclenche les actions à effectuer sur les données en sollicitant le modèle adéquat et renvoie la vue correspondant à la demande. On n’y retrouvera donc pas d’instruction d’habillage proprement dit.



Utilisation d’un framework

Programmation

Un framework (qui pourrait être traduit par “espace de travail modulaire”) est constitué d’un ensemble de bibliothèques et de conventions servant à la réalisation d’applications informatiques. En imposant un certain nombre de règles et de briques logicielles, un framework vise à fournir un cadre de travail rigoureux permettant de produire rapidement des applications cohérentes, fiables et aisées à maintenir.

Au nombre des avantages des frameworks on peut citer :

– la formalisation des procédures;
– la standardisation des procédures;
– la convergence des procédures;
– la modularité du code;
– la réutilisation du code.

A contrario, en ce qui concerne les inconvénients d’un recours à un framework, on pourra trouver :

– la rigidité de l’architecture;
– l’inadaptation à certains contextes (lourdeur);
– une courbe d’apprentissage parfois longue.

Il existe aujourd’hui un grand nombre de frameworks quelque soit le langage de programmation privilégié. En voici les plus évidents :

En PHP :

Zend Framework
Symfony
Laravel
Phalcon
Yii
CodeIgniter
CakePHP

En Python :

Zope
Django
Pylons



Apache et les fichiers htaccess

Systèmes

Le serveur web Apache permet d’ajouter des directives de configuration répertoire par répertoire en les précisant dans de simples fichiers textes nommés ‘.htaccess’. Ceux-ci auront pour effet de modifier localement le fonctionnement du serveur Web. Il est ainsi possible d’imposer au serveur des comportements spécifiques pour le répertoire (et les sous-répertoires) dans lequel se trouve le ‘.htaccess’ sans devoir toucher au fichier de configuration central d’Apache ‘httpd.conf’.

Le domaine d’application des fichiers ‘.htaccess’ est assez vaste. A travers eux et les directives qu’ils contiennent on va pouvoir par exemple pour un site web (une portion de site web, ou un répertoire isolé) ajuster plus finement les redirections, les réécritures d’URL, les restrictions d’accès ou encore la redéfinition des messages d’erreur.

Redéfinition des messages d’erreur via un fichier ‘.htaccess’

L’erreur “404 – pas trouvé” est un message souvent rencontré par les internautes. Il est généré par le serveur lorsqu’une page inexistante est demandée. Le message est alors envoyé au client qui est à l’origine de la requête et le navigateur Web se charge de l’habiller (très sommairement).

Afin de remplacer l’interprétation standard du message ‘404’ par une page que vous pouvez contrôler, il suffit de préciser une directive dans un fichier ‘.htaccess’. Elle tient en une seule ligne et présente la syntaxe suivante:

ErrorDocument error-code filepath

Le premier élément de cette commande donne le nom de la directive utilisée, le deuxième élément fournit le code d’erreur traité et le dernier élément précise le chemin d’accès du fichier qui sera envoyé.

Contenu d’un fichier.htaccess effectuant une redéfinition d’erreur:

ErrorDocument 404 /error.html

En conséquence, la page ‘error.html’ (situé à la racine du serveuer Web) sera systématiquement envoyée dès qu’un document inxesitant aura été demandé.



Cron et la gestion de tâches automatiques

Systèmes, Unix

Sous Unix/Linux le système “cron” permet de lancer périodiquement des commandes ou processus. On s’en sert par exemple pour automatiser des sauvegardes, des transferts de fichier, des extractions de bases de données, des envois de messages…

Le logiciel qui orchestre tout cela est communément appelé “cron” (en fait le démon “crond” chargé en mémoire). Il va lancer à intervalles réguliers ou à des moments bien déterminés différentes tâches.

Les commandes que cron devra exécuter (par exemple une sauvegarde) sont précisées dans une table de référence. Celle-ci contient les informations relatives aux moments auquels il faut exécuter certaines commandes et le nom des commandes ou les chemins d’accès des scripts à exécuter. Cette table peut-être éditée avec l’utilitaire “crontab” (passage automatique via l’éditeur déterminé par la variable d’environnement VISUAL ou EDITOR – le plus souvent “vi”).

Pour mettre à jour la table de référence de cron, vous pouvez exécuter la commande suivante:

> crontab -e

L’information présentée en réponse est formatée ligne par ligne, chaque ligne reprenant la définition du moment d’exécution suivie de la commande ou du script à exécuter. En voici la structure:

minute hour day month dayofweek task

Le premier champ représente les minutes (0-59).
Le second champ représente les heures (0-23).
Le troisième champ représente les jours du mois (1-31).
Le quatrième champ représente les mois de l’année (1-12).
Le cinquième champ représente les jours de la semaine (0-6 dimanche=0).
Le sixième champ représente la commande ou le script à exécuter.
Le septième champ représente l’instruction à exécuter.

Analysons cela à travers quelques exemples:

> 15 20 * * * echo “hello” >>/tmp/log_cr.txt

(lancement de la commande echo tous les hours à 20h15)

> 50 6 1 * * /home/scripts/bck.sh

(exécution de bck.sh le premier jour de chaque mois à 6h50)

> 00 10 1-5 * * /usr/bin/hello.sh >>/dev/null

(exécution de hello.rb du 1er au 5 de chaque mois à 10h00)