Archives par étiquette : php

PHP

ChronoSIDORE : explorons les données d’ISIDORE avec SPARQL #2

ChronoSIDORE n’est pas le nom d’une nouvelle espèce de dinosaures, c’est le nom d’une application web qui utilise les ressources d’Isidore. ChronoSIDORE est donc un petit « mashup » que j’ai programmé pendant mes congés d’été. L’idée est double, poursuivre l’exploration concrète des possibilités d’un outil comme Isidore et donner des idées à d’autres personnes, en particulier dans le monde des bibliothèques et de la documentation, pour développer d’autres mashups s’appuyant soit sur l’API d’Isidore soit sur son SPARQL endpoint.

Que propose-t-il ?

ChronoSIDORE, accessible sur www.stephanepouyllau.org/labs/isidore/chronosidore, propose une autre façon de « voir » les ressources d’Isidore ; différente des vues traditionnelles en « pages de résultats » comme cela est le cas dans les bases de données bibliographiques ou catalogues. Ce mashup propose une vision des ressources en « tableau de bord » : il s’agit de projeter sur une frise chronologique un ensemble de ressources issues d’une ou de plusieurs requêtes SPARQL. Ainsi, une vision plus globale est proposée permettant une représentation différente de la répartition des ressources : dans notre cas, une mise en lumière de l’évolution disciplinaire des ressources fondée sur la catégorisation automatique effectuée par Isidore. ChronoSIDORE offre la possibilité de « voir » l’évolution chronologique des tendances disciplinaires pour un ensemble fini de ressources documentaires définit dans Isidore ou « source » : il peut s’agir des publications d’un laboratoire (à la condition qu’il possède une collection dans HALSHS), des articles d’une revue, des notices d’une base de données, des billets d’un carnet de recherche (voir la liste des sources dans l’annuaire d’Isidore). ChronoSIDORE propose deux types de requêtes SPARQL : l’une est orientée « sources » la seconde est orienté « auteurs » (permettant de projeter sur la frise les ressources d’un auteur). ChronoIsidore est un exemple de mashup possible, bien d’autres mashup sont possibles (autour des langues, des types de documents…).

Comment fonctionne-t-il ?

N’étant pas un développeur professionnel, j’ai fais avec mes connaissances en PHP, Xpath, SPARQL et Javascript pour développer. J’en profite pour remercier ici mes collègues Laurent Capelli, Shadia Kilouchi et Jean-Luc Minel qui m’ont aidé, en particulier sur SPARQL. Ainsi, je pense qu’une équipe de développeurs professionnels ferait beaucoup mieux, mais j’ai pensé aussi qu’il serait bien de montrer que l’ancien étudiant en histoire et archéologie du Moyen Age que je suis est capable d’exploiter avec un peu de PHP, les gisements de données enrichies proposés par Isidore, en espérant que cela donnera des idées à d’autres. J’en profite pour ré-affirmer ici le rôle et l’importance des ingénieurs en digital humanities dont les métiers sont multiples et qui interviennent à différents niveaux de technicité : Il faut des très grands spécialistes, érudits mais aussi des intermédiaires qui vont chercher la compétence à l’extérieur et l’adapte aux besoins SHS . On fait souvent le reproche aux ingénieurs du CNRS, surtout en digital humanities, de ré-inventer l’eau chaude, mais je pense qu’ils développent des outils, des méthodes qui sont adaptés à des publics présentant une multitude de rapports au numérique et différents niveaux d’appropriation et c’est très important. Il faut parfois avoir un outil imparfait, ou un démonstrateur fonctionnel pour offrir un service qui permettra à certains de profiter d’outils communs, fondés sur des standards ouverts et bien documentés et de « sauter le pas », ensuite on peut toujours améliorer les fonctionnalités. Je préfère cela à deux extrêmes : passer cinq ans à faire un outil qui ne fonctionnera jamais et qui sera dépassé avant de sortir (car nous n’avons que trop rarement les moyens de faire vite et bien) et dire qu’au prétexte que cela existe en ligne, il ne faut rien, s’en contenter, faire avec, et ne rien tenter car on n’égalera jamais les autres. Il s’agit parfois de faire juste « un pas de plus » pour ouvrir des données aux autres et savoir que ce « pas » est maitrisé, accompagné par des collègues du monde académique peut être plus sécurisant que de plonger de suite dans jungle des outils en lignes et des « consultants » (même si, comme je l’ai dit, cela peut être nécessaire). J’aime bien l’idée que ChronoSIDORE donnera peut-être des idées à d’autres, nous en reparlerons au THATCamp Paris 2012 en septembre.

ChonoSIDORE réalise en fait plusieurs tâches :

Il interroge le triple store RDF d’Isidore : il s’agit d’une base de données RDF qui contient l’ensemble des informations d’Isidore formalisées en RDF et proposées selon les principes du linked data.
Il utilise pour cela le langage normalisé et international SPARQL (W3C) qui permet d’interroger les triplets RDF.
Il assemble les informations reçues du triple store sous la forme d’un flux de réponse Xml lisible avec l’application timeline créé dans le cadre du projet Simile du MIT (plutôt que refaire un système propre, j’ai préféré utiliser cet outil, même si je le trouve quelque peu rigide, il existe aussi d’autres systèmes : par exemple Timeline JS mais quelque peu différent).

Quelques limites

Il s’agit d’une version bêta, en fait un démonstrateur, donc il présente des limites. Deux sont à signaler :

Isidore catégorise automatiquement via un corpus de référence (HALSHS) et à l’aide de signatures sémantiques : cela peut donc générer des erreurs de catégorisation. Pour aller plus loin, voir les principes de catégorisation dans Isidore avec la vidéo de présentation des systèmes d’Isidore par Fabrice Lacroix, président d’Antidot, lors de l’université d’hiver du TGE Adonis à Valpré en décembre 2010 (ouverture d’Isidore).

Isidore ne catégorise pas toute les ressources qu’il moissonne : cela dépend de la richesse sémantique des métadonnées : plus les métadonnées moissonnée seront riches (description, résumé, mots-clés) plus la catégorisation proposée par Isidore sera pertinente et donc utilisable dans ChronoSIDORE. Donc toutes les ressources ne « montent » pas dans la frise chronologie.

Je vous invite donc à utiliser ChronoSIDORE, à le tester, à le faire « craquer » et si vous le souhaitez vous pouvez laisser un commentaire, des idées, des critiques…

Stéphane.

Tout ce qu’il reste à faire…

Le développement de l’archive ouverte MédiHAL fut court, 3 mois en tout et avec une toute petite équipe (3 personnes). Même si nous avons largement utilisé le framework HAL, il reste plein de choses à faire, à améliorer, à reprendre, à redessiner et à écouter les chercheurs, documentalistes et bibliothécaires qui déjà par dizaines nous ont écrit pour nous encourager, nous demander conseil avant de se lancer. Ils nous ont aussi dit que MédiHAL est une bonne chose à l’heure des départs massifs en retraite dans le monde de la recherche. Certains nous ont demandé des choses précises, d’autre nous ont signalé des bugs, etc.
Je suis très heureux de voir que des développeurs nous ont demandé l’accès à l’api de HAL pour développer des widgets de chargement de masse et de visualisation. Au cours des prochains mois, MédiHAL trouvera petit à petit son rythme et je tiens à remercier toutes les personnes qui nous ont contactées. Elles ont exprimé leurs critiques, positives ou négatives, et leurs doutes et/ou un soutien. Certains déposeront dans quelques semaines ou quelques mois, ils sont les bienvenues.

Bon dimanche.

Stéphane.

Ca, mais si souviens toi, c’était où déjà ? ou le geocaching scientifique

Pour noël, j’ai eu un GPS ! Ceux qui me connaissent me diront que n’ayant pas de voiture à Paris, ce n’est pas très utile. Et pourtant, si l’ont veut géo-référencer les photos de noël et le déballage des cadeaux par les enfants, cet outil devient très pratique, testons un peu…

J’ai donc un GPS pour mon D90 : il s’agit de l’unité GP-1, qui se place à la place du flash ou sur le coté. Pour info, dans le Nikon P.6000, un compact, le GPS est en standard.

Mes grands-parents, s’ils étaient en vie, diraient : « Mais que fait Stéphane, dans le jardin, avec un appareil photographique pointant vers le ciel ? » Au début, la première capture des satellites est un peu longue : plus de 5 s., c’est déjà embêtant si vous devez déclencher tout de suite… passons. En laissant l’appareil en veille, ça va mieux. Ensuite cela semble assez précis (même dans le jardin), l’altitude aussi (testé avec un bon vieil altimètre).

Clic-clac, les coordonnées et l’altitude sont bien capturées et incluses dans les méta-données EXIF de l’image. Avec Exiftool (et tous les outils qui tourne autour), par exemple, il est facile de voir et d’exporter ces valeurs de positionnement (extrait) dans ExiftoolGUI…

De les sortir sous la forme d’un tableau HTML (voir plus bas)…

EXIF	GPSVersionID	2.2.0.0
EXIF	GPSLatitudeRef	North
EXIF	GPSLongitudeRef	West
EXIF	GPSAltitudeRef	Above Sea Level
EXIF	GPSTimeStamp	11:24:24
EXIF	GPSSatellites	05
EXIF	GPSMapDatum
EXIF	GPSDateStamp	2008:12:25
Composite	GPSAltitude	36 m Above Sea Level
Composite	GPSDateTime	2008:12:25 11:24:24
Composite	GPSLatitude	44 deg 45′ 15.21″ N
Composite	GPSLongitude	0 deg 34′ 31.58″ W
Composite	GPSPosition	44 deg 45′ 15.21″ N, 0 deg 34′ 31.58″ W
Composite	SubSecDateTimeOriginal	2008:12:25 13:21:45.00

…Et bien entendu, il est très facile d’exploiter cela avec un outil cartographique en local, tel que l’excellent GeoSetter dont une version en français est disponible :

ou bien via l’outil carte de Flickr (là, rien à faire de particulier, les photos sont positionnées par défaut lors du chargement).

Tout cela peut aussi ce faire via son Firefox avec IExif, Dans la monde Google avec Picasa et Google Earth, etc.

Si le format EXIF vous pose un problème, il est possible de stocker ces données dans du MIX. C’est évidement plus complexe pour l’exploitation, du moins pour le grand public.

Extraire ce type de méta-données avec du Perl est très facile : le programme perl exiftool de Phil Harvey est très bien pour cela : une petit ligne du type « Exiftool -exif:GPSAltitude -h img > mes_exifs.html » et l’on récupère l’altitude d’une série d’images dans un tableau HTML.

Avec du PHP c’est possible aussi : il faut charger les extensions php_mbstring et exif (dans cet ordre) dans le php.ini ; ensuite il est possible d’utiliser la fonction exif_read_data.

Bref, bientôt TOUS les appareils géo-tagueront en automatique et l’on ne comprendra pas pourquoi les photos anciennes ne le sont pas (les documentalistes vont avoir du travail) : ainsi les interfaces d’intérogations vont évoluer : un fond de carte, des outils de sélection (ronds, carrés, etc.), des plots de couleurs, des requêtes externes, des réponses aux questions qui s’afficheront sous la forme d’un chapelet de marqueurs. Au CN2SV, nous avons commencé à le faire des cartes et des atlas anciens, j’imagine ce que nous allons faire dans quelques années !

Mais j’y pense… le temps d’écrire ce billet et tout cela doit déjà exister, j’en suis sûr (et en open-source ?). En attendant la suite, j’espère que les artistes vont trouver des applications moins « utiles » que celles décrites ici. Je m’en retourne à mon mash-up de noël.

Joyeuses fêtes,

Stéphane.

Frises chronologiques sur le web : utilisation de Timeline pour faire un mashup AJAX avec PHP et MySQL

Bonsoir,

Je profite d’un week-end loin de Paris et d’un long voyage en train pour décrire (mais avec beaucoup de retard) un petit mashup que j’ai réalisé pour le site @.ampère et l’histoire de l’électricité. L’idée de départ était de développer des chronologies avec l’outil Timeline mis au point par le MIT et que pas mal de développeurs connaissent et utilisent. Timeline permet de créer des frises chronologiques à l’image de celles encore présentes dans les livres scolaires d’histoire (nous avons tous rêvés devant ces frises en couleurs présentant l’histoire de l’Homme par exemple). C’est outil utilise des éléments en javascript et du XML : c’est donc un système basé sur AJAX. Dans le site @.ampère nous voulions faire une frise avec des éléments historiques différents le tout devant être synchronisé :

une sous-frise sur les grands personnages de l’histoire de l’électricité
une sous-frise sur les grandes découvertes de ce même domaine

Dans Timeline, les évènements (events) sont stockés dans un fichier XML très simple. Dans le but d’inclure Timeline dans le système d’information (SI) du site, nous avons utilisé deux tables MySQL pour mettre les données brutes (date, contenu de l’évènement, etc.). Un script PHP utilisant DOM réalise alors une présentation XML de ces données : en sortie, nous avons deux fichiers XML, un pour chaque sous-frise, qui sont normés suivant le schéma des fichier nécessaire au fonctionnement de Timeline. Nos deux tables MySQL sont indépendantes du système AJAX de Timeline : c’est PHP/DOM qui formate les données en XML suivant la grammaire Timeline. Nous avons d’ailleurs un autre programme PHP qui présente ces même données sous la forme d’une page web classique. Le schéma suivant en résume le modèle :

Les deux fichiers XML sont stockés dans un répertoire du serveur et chargé dans l’application AJAX qui gère Timeline. Le XML resemble à ceci :

<?xml version="1.0" encoding="iso-8859-1"?><data>

<event start="Jan 00 1544 00:00:00 GMT" end="Jan 00 1603 00:00:00 GMT"

image="AMP_1015.jpg" isDuration="true" title="William GILBERT">(1544-1603)</event><event start="Jan 00 1666 00:00:00 GMT" end="Jan 00 1736 00:00:00 GMT"

isDuration="true" title="Stephen GRAY">(1666-1736)</event> ...

</data>

Pour le tout fonctionne, il nous a fallu ajouter un petit programme php de vérification de la forme des dates/heures histoire de ne pas avoir de bug dans l’une des deux sous-frises. Pour terminer nous avons ajouté, dans le fichier javascript de la frise (main.js) qui pilote l’affichage écran, les instructions suivantes :

bandInfos[1].eventPainter.setLayout(bandInfos[1].eventPainter.getLayout());

tl = Timeline.create(document.getElementById("my-timeline"), bandInfos, Timeline.HORIZONTAL);

Timeline.loadXML("kronos1.xml", function(xml, url) { eventSourceA.loadXML(xml, url); });

Timeline.loadXML("kronos2.xml", function(xml, url) { eventSourceB.loadXML(xml, url); });

Nous avons une « bandInfos » dans laquelle nous « chargeons » les deux fichier XML : kronos1.xml et kronos2.xml. Ce chargement est réalisé au sein des deux eventSource (A et B). Ce fichier, main.js, qui est un fichier javascript pur est chargé dans une page HTML (ou PHP dans notre cas) par l’utilisation d’une simple balise <script> dans l’entête. La frise « double » est ensuite affiché dans le code HTML via un « id » de balise <div> :

<div id="my-timeline" style="height:800px; width:100%;"></div>

Le tour est joué, nous avons une belle frise chronologique présentant de façon synoptique ces deux types d’évènements. Voici le résultat :

Bonne fin de week-end,

Stéphane.

PS : Merci à Marie-Hélène Wronecki pour le travail sur la base de données MySQL.

Trancodage de dates informatiques

Bonsoir,

Un petit script php très simple pour convertir une date du type AAAA-MM-JJ HH:MM:SS en date normée suivant RFC 822 utilisée dans les flux RSS ou dans le monde OAI-PMH :

$datedepart = '2007-09-10 00:00:00'; // on entre la date (qui peut venir d'un champ de type datetime de SGBDR : MySQL, PostgreSQL, etc.)

list($date, $hours) = split(' ', $datedepart);
list($year,$month,$day) = split('-',$date);
list($hour,$min,$sec) = split(':',$hours);

$date = date(r,mktime($hour, $min, $sec, $month, $day, $year));
print "$date";

Stéphane.

Source : http://www.phpfreaks.com/quickcode/from-MySQL-datetime-to-RFC-822-for-RSS/597.php

KML simple et géodonnées (partie 1)

Il est possible de construire rapidement de petites applications simples permettant d’exploiter des documents issus d’archives visuelles (cartes, photos, plans) en les connectant a des données bibliographiques. Ces applications utilisent de plus en plus les langages du web (et, depuis 2005, ceux du web 2.0) et elles se développent autour d’XML. Voici une première partie/introduction au KML et le début d’un exemple avec le géo-référencement 2D de cartes anciennes via Google Maps, du KML et du XML.

Le KML (Keyhole Markup Language) est une grammaire XML permettant d’afficher et de gérer des données dans Google Maps et Earth. Il offre la possibilité de poser des points, tracer des lignes, des polygones. Dans Google Earth, s’y ajoute les angles de vue, les objets 3D simples ou texturés. Mais l’une des fonctionnalités les plus intéressante pour la recherche reste l’enrichissement en données externes. KML peut diffuser des données XHTML riches (textes, images, videos), des images plaquées sur la photo satellitaire, etc…

Il existe une version compressé du KML, le KMZ. Pour ceux qui ont utilisé comme moi du VRML (Virtual Reality Modeling Language), nous avions aussi une version « Gzipé » du langage : le .wrz (à la place du .wrl). le KMZ encapsule aussi les images qui peuvent être liées au fichier KML. Il est possible de fabriquer du KMZ avec un simple compresseur : WinZip, Gzip, etc.

Sur le plan syntaxique, le KML se présente comme du XML :

<?xml version= »1.0″ encoding= »UTF-8″?>
<kml xmlns= »http://earth.google.com/kml/2.2″>
<Placemark>
<name>Siège du CNRS</name>
<description>Paris, le siège du CNRS.</description>
<LookAt>
<longitude>2.264605600614077</longitude>
<latitude>48.84727288728012</latitude>
<altitude>0</altitude>
<range>171.6689944655567</range>
<tilt>-6.848248640637841e-011</tilt>
<heading>0.0004740658326556625</heading>
</LookAt>
<Point>
<coordinates>2.264605600614077,48.84727288728013,0</coordinates>
</Point>
</Placemark>
</kml>

Ce petit fichier KML permet de placer dans Google Earth ou Maps, un point localisé sur le siège du CNRS, l’élément <LookAt/> correspondant au point de vue de la caméra qui « regarde » ce point. <Placemark/> encapsule le <Point/> géocodé présentant la latitude et la longitude. Dans le monde Earth / Maps de Google, les coordonnées géographiques sont en degrés décimaux (comptés positivement vers le Nord pour la latitude, et vers l’Est pour la longitude). Ici, le géocodage est très précis (2.264605600614077), mais si vous utilisez l’API de Maps, la précision est de l’ordre du mètre. Autre limite, dans Google Maps, seuls certains éléments peuvent être utilisés : les points, les lignes, les polygones, les styles, les icônes et les liens et l’application de couches multiple (placage d’images), mise en œuvre de dossiers et types de vues. Pour le moment (version 2.2 du KML) la 3D n’est pas utilisée (nous sommes dans Maps, donc le royaume de la 2D).

Ce petit exemple, permet de ce lancer dans la construction de fichiers KML et ainsi enrichir en information de toutes sortes de cartes dans le vaste « bac à sable » que peut être Google Maps ou Earth. De nombreux scientifiques, les géographes principalement, utilisent déjà ce format. J’ai découvert aussi ce site qui présente Google Earth et le KML pour les enseignants du secondaire. Le KML n’est pas le seul format XML dans le domaine des « géo-formats/2D/3D » : il y a le WMS, WFS et GML venant du monde de la géographie, les formats pour « services web » : AtomPub, GeoRSS et le KML/Z (avec d’autres limites cependant).

Dans le cadre du CN2SV, nous avons publié l’inventaire d’un fonds de cartes topographiques anciennes (XIXe-XXe siècle) de la cartothèque du centre de documentation REGARDS-CNRS. Nous avons décidé de coupler ce fonds de cartes, après numérisation, avec une base de données bibliographique/documentaire classique. Pour cela, nous avons utilisé une base de données intermédiaire qui, à partir des données lat./long. des quatres angles d’une carte, a pour mission de stocker des données pour produire à la fois du KML (pour l’instant sous la forme de petit fichier, donc nous sommes en mode asynchrone) qui peut être utilisé dans Google Earth pour visualiser l’emprise de la carte, ces villes importantes, etc. Mais aussi du XML compatible avec l’API de Google Maps (qui est légèrement différent du KML natif, du moins dans sa version 2.2 ).

Dans un second temps, j’ai développé une petit programme PHP qui exploite ces fichiers XML (pour l’API…) dans un contexte l’application riche. Du KML simple, nous passons dans un micro format XML propre (mais nous pourrions faire cela avec du KML directement, c’est juste une histoire d’optimisation du fichier pour l’API de Google Maps), ainsi pour chacune des cartes nous avons ceci :

<?xml version= »1.0″ encoding= »UTF-8″?>
<mygeod xmlns= »http://www.cn2sv.cnrs.fr/xml/mygeoc/0.1″>

<markers>
<marker lat= »-20.53105″ lng= »47.24332″ label= »Ville d’Ambositra » html= »Informations sur la ville d’Ambositra <br>avec la base de données REGARDS-ADES-CNRS » infolink= »query.php?value=Ambositra »/>
<marker lat= »-20.62105″ lng= »47.20332″ label= »Carte de Madagascar » html= »Informations sur la ville d’Ivato <br>avec la base de données REGARDS-ADES-CNRS » infolink= »query.php?value=Ivato+Madagascar »/>
<marker lat= »-19.871795326377995″ lng= »47.03521728515625″ label= »Carte de Madagascar » html= »Informations sur la ville d’Antsirabe <br>avec la base de données REGARDS-ADES-CNRS » infolink= »query.php?value=Antsirabe »/>
<marker lat= »-20.27137605095937″ lng= »44.31661605834961″ label= »Carte de Madagascar » html= »Une carte est disponible » infolink= »?id=R_MADA11_04_00014″/>
<line colour= »#ff0000″ width= »5″>
<point lat= »-19.40″ lng= »45.32″/>
<point lat= »-19.40″ lng= »48.11″/>
<point lat= »-21.20″ lng= »48.11″/>
<point lat= »-21.20″ lng= »45.32″/>
<point lat= »-19.40″ lng= »45.32″/>
</line>
<center lat= »-20.33″ lng= »46.90″ zoom= »8″/>
</markers>

</mygeod>

Ce fichier XML permet de délimiter la couverture de carte et de pointer des lieux (les « markers » de Google Maps). Les attributs sont très simples :

label : titre de la vignette/popup
html : contenu de la vignette/popup
lat : latitude
lng : longitude
zoom (pour <center/>) : facteur du zoom d’entrée dans la carte
infolink : lien vers le connecteur de/des bases de données à interroger (mais on pourrait imaginer une chose avec du xlink et xpointer si l’on veut rester dans le monde XML)

Il suffit d’utiliser de l’API de Google Map pour monter l’application. Mais cela sera pour le prochain billet…

Stéphane.

PS : Le format KML est relativement simple, mais un ouvrage de référence en français manque (à moins qu’il soit sous presse).

Zend Framework : un nouveau site pour la communauté française des utilisateurs.

Bonjour,
De retour de vacances, je mets au propre quelques notes informatiques glanées tout au long de l’été. Utilisateur du Zend Framework depuis quelques semaines (pour une application en test pour le moment), j’ai découvert dernièrement que la communauté française des utilisateurs du Zend Framework s’organisait autour d’un nouveau site web, très bien fait et plein d’informations. Un très bon forum, très professionnel, permet de poser des questions simples ou complexes suivant son niveau de pratique du Zend Framework.
Le Zend Framework (ZF) est un projet PHP créé par la société Zend, grande prêtresse du langage PHP dans le monde. Le ZF est un ensemble de librairies permettant d’accélérer le développement d’applications PHP professionnel. Il permet aux entreprises d’appuyer leurs outils sur une infrastructure robuste orienté MVC (modèle, vue, contrôleur). En terme de sécurité, l’utilisation du ZF entraine des gains importants, notamment au niveau des injections SQL. Comme tous les frameworks, ZF n’est cependant pas très simple au début, il faut bien comprendre le système MVC avant tout.
Mais un signe ne trompe pas, la communauté ZF augmente et en mai 2007, l’association française des utilisateurs de PHP, a organisé une présentation ZF dont la vidéo (amateur ?) est en ligne sur http://php.developpez.tv. Certaines applications « grand public » utilisent ZF et un premier CMS vient de voir le jour : http://zfcms.tebe.ch (démonstration de l’outil de gestion : http://zfcms.tebe.ch/admin/ avec identifiant/mot de passe : admin/admin).
ZF est un framework à suivre dans l’environnement PHP.

Stéphane.
PS : un tutoriel plutôt bien fait existe sur le site : developpez.com

Un moteur de recherche de codes source ?

Bonjour,
Le moteur de recherche Krugle annonce pour septembre 2007 une version entreprise de son moteur de recherche. Il s’agit donc d’un moteur de recherche qui indexe le contenu des codes sources déposés dans un forum ou dans des pages web (il y en aurait 20 millions de fichiers de code source sur le web selon Krugle, source : 01net). Il existe aussi Google Code Search (version en français) issu du « Labs » Californien de Google. Encore en développement il pourrait s’agir d’une sources non négligeable pour les développeurs. Si l’on veut recherche des bouts de code sur la commande addslashes en PHP, il suffit de taper lang:php addslashes. Dans les résultats de recherche, le type de licence du source trouvé est indiqué (GPL, LGPL, BSD, etc.). A vos codes…et bonne fin de semaine. Stéphane.

Un peu de javascript

Bonjour,
Il est important, parfois, de revenir à la programmation directe : dans le « coeur du code » (utilisez Zend, PDO…, c’est super mais bon l’assemblage au bout d’un moment…). Au cours d’un développement ou plutôt d’un patchage d’ICEberg, j’ai du surmonter le problème du document.getSelection(); en javascript qui ne fonctionne qu’avec les navigateurs Mozilliesque (Firefox, Netscape, Mozilla). document.getSelection(); n’est donc pas compatible avec IE. Je suis dans une application en PHP et j’ai besoin du document.getSelection(); pour transmettre via des variables une selection de texte éffectuée par l’internaute sur la page consultée pour l’injecter ensuite dans un formulaire. Si IE n’existait pas, nous pourrions nous contenter de :

location.href='formAK.php/user?action=add& description='+encodeURIComponent(document.getSelection())+';

Seulement voilà, il y a IE et document.getSelection(); renvoit une belle erreur javascript. Mais il y a une petite solution très simple qui permet de rendre cette action compatible quelque soit votre navigateur préféré (sous MacOS X, cela fonctionne aussi). Plutôt que de détecter le navigateur (son nom via : navigator.appName), il plus intéressant de détecter la méthode (ou l’objet) dont le fonctionement avec les navigateurs n’est pas possible (ou mal gérée). Ainsi, avec un système conditionnel classique et une nouvelle variable « methodeselection » :

if (document.getSelection) methodeselection = document.getSelection(); else if (document.selection) methodeselection = document.selection.createRange().text; else return;

Préparé pour une page web, nous pouvons écrire :

function envoyer_une_selection_quelquepart() { if (document.getSelection) sel = document.getSelection(); else if (document.selection) sel = document.selection.createRange().text; else return; location.href='http://www.monsite.fr/?action=ajouteramonforumulaire& description='+encodeURIComponent(sel)+'; }

Bonne fin de semaine,
Stéphane.

Utilisation massive de la librairie GD pour PHP : les lettres de Stephen Gray dans le site @.ampere

Bonjour,
Dans le site @.ampere (direction ; C. Blondel, CNRS) dont je suis le webmaster, j’ai placé des lettres de Stephen Gray (voir dans Wikipedia), pour le zoom j’utilise la GD de PHP, cette librairie est connue mais elle rend bien des services quoiqu’un peu lente. Je l’utilise pour le zoom 100% 75% 50% 25% mais aussi dans le site du CN2SV pour le génération d’images « vignettes » à la volée. La GD a été intégré à PHP depuis la version 4.3 et commence à faire du JPEG2000. En complément, il y a surtout la fonction « iptcparse » qui permet de lire les méta-données IPTC et même de les mettre à jour avec « iptcembed ».
Stéphane.