Les modèles standard

Dans la version v1 de Rainette, l’insertion de données météorologiques dans un squelette se fait toujours via un modèle standard :

• rainette_conditions, pour les conditions temps réel,
• rainette_previsions, pour les prévisions à n jours,
• rainette_infos, pour les informations sur la ville,

qui fait uniquement appel à un filtre dont le nom est tiré de celui du modèle. Pour le modèle rainette_conditions, par exemple, le code de la version v1 de Rainette est le suivant :

On s’aperçoit que deux arguments sont toujours passés à ces modèles - et donc aux filtres - à savoir :

• le code du lieu
• et le sous-modèle qui définit la structure exact de l’affichage.

La première évolution consiste à ajouter en dernier paramètre des filtres le service utilisé, qui par défaut prendra la valeur du service Weather.com®. Cela correspond dans les modèles standard à un paramètre « service ». Ce paramètre prend les valeurs « weather », « wwo », « wunderground », « owm ». En outre, on unifie les filtres conditions, infos et prévisions pour n’avoir plus qu’une seule fonction rainette_coasser() auquel il est donc nécessaire de passer le mode.

Le code du modèle rainette_conditions est donc modifié comme suit :

Pour les prévisions et afin de gérer les différents intervalles horaires, l’interface actuelle sera modifiée pour prendre en compte les nouveautés apportées par les services autres que Weather.com®.

Le chargement des données météorologiques

Le chargement des données météorologiques est confié à une fonction unique charger_meteo() qui est appelé par le filtre unifié rainette_coasser(). Cette fonction a aussi évolué en v3 pour, d’une part, intégrer l’argument service et d’autre part, revêtir une forme standard pour les conditions, prévisions et infos.

Cette fonction, suivant qu’elle lit le cache ou qu’elle le recrée en interrogeant le service distant concerné, appelle une liste de fonctions standardisées pour chaque service et renvoie le fichier cache correspondant à la demande. Le code est le consultable sur la zone : http://zone.spip.org/trac/spip-zone...

Cette nouvelle version de Rainette va plus loin dans la standardisation de cette fonction de chargement. Grâce à une configuration poussée des services, il est possible de charger la majorité des données de chaque service de façon commune à partir de la fonction service2donnees($configuration, $mode, $flux, $periode). Le code de chargement spécifique à chaque service est dès lors très réduit : conversion de système d’unité, calcul des états météorologiques standard...

Le codage d’un service

La structure de codage d’un service est la suivante :

• chaque service est codé dans un fichier PHP portant l’alias du service - weather.php par exemple,
• et inclut une liste de fonctions standard appelées par la fonction de chargement des données précitée ainsi que toutes les sous-fonctions, globales de configuration du service et constantes propres.

Les fonctions standardisées à coder pour chaque service sont :

• ${service}_service2configuration, qui renvoie la configuration statique du service.
• ${service}_service2cache, qui renvoie le nom du fichier de cache calculé.
• ${service}_service2url, qui renvoie l’url complète de la requête correspondant à la demande.
• ${service}_complements2${mode}, qui complètent le tableau des données collectées de façon standard par le service.

La fonction ${service}_service2configuration

Cette fonction renvoie la configuration du service pour le mode considéré, à savoir :

• la configuration générale du service comme les crédits, la langue par défaut, les valeurs par défaut de la configuration dynamique modifiable par l’utilisateur...
• la configuration du mode considérée avec le format du résultat de la requête (JSON ou XML), la période de mise à jour et la description de toutes les données météorologiques fournies par le service.

La fonction ${service}_service2cache

Cette fonction calcule pour chaque service le nom du fichier cache en fonction du lieu et du type de données requis. De façon générale, ce fichier .txt est stocké dans un sous-dossier du cache SPIP nommé rainette/${service}/.

La structure du nom du fichier est : ${lieu}_${typedonnees}[_${langue}] où :

• ${lieu} est le nom du lieu en majuscule pour lequel les caractères tels que les points, virgules, slash, plus... sont remplacés par un underscore.
• ${typedonnees} est le type de données, « infos », « conditions » ou « previsionsXX », XX représentant l’intervalle horaire des prévisions, soit 24, 12, 6, 3 ou 1.
• ${langue} le code de la langue exprimé selon le standard SPIP. Ce code n’est présent que pour les services supportant le multilinguisme et dans le cas où l’on l’utilisateur a choisi d’afficher les résumés du service et non ceux proposés par Rainette sur le modèle de Weather.

Le lieu peut-être parfois composé comme Paris,France ou latitude,longitude. Dans ce cas, la caractère séparateur est remplacé systématiquement par un tiret « - ».

La fonction ${service}_service2url

Cette fonction construit l’url de la requête adressée au service distant en fonction de la demande qui lui est faite. Quand l’API du service l’autorise la fonction élabore la requête la plus optimisée par rapport à la demande : les conditions, les prévisions et les infos font l’objet de requête différente. C’est le cas de tous les services à l’exception de Yahoo Weather et de Open Weather Map pour la requête d’information uniquement.

Suivant le service il est possible ou pas de préciser le système d’unités utilisé pour les valeurs numériques et bien entendu la clé d’inscription. Pour Wunderground et Open Weather Map, il est aussi possible de préciser la langue des textes.

Les fonctions ${service}_complement2${mode}

Ces fonctions complètent le tableau standard construit uniquement à partir des données brutes issues du service et fournies par la fonction service2donnees. Si aucun complément n’est requis il est possible de ne pas coder cette fonction dans l’API du service.