WIIP

goog.require

Cette fonction est à la base du système de paquets de Google Closure. D'une façon similaire à la fonction require_once de PHP, elle permet d'inclure les dépendances. Techniquement parlant, elle charge les scripts nécessaires en ajoutant des balises SCRIPT. Le problème c'est que le chargement de ces scripts se fait de façon asynchrone.

Google vient de publier Closure qui est un ensemble d'outils destinés à faciliter le développement d'interfaces Web. Basé sur HTML + CSS + Javascript, cette boite à outils comprend notamment :

• Le compilateur Closure : ce n'est pas vraiment un compilateur, mais plutôt un outil qui permet d'optimiser du code Javascript. Il effectue une série de vérification sur le code, supprime les parties non utilisées et en réécrit certaines pour accélérer l'exécution du script.
• La bibliothèque Closure : c'est un ensemble de script Javascript qui fournit des contrôles (boutons, menus...) pour créer des interfaces utilisateurs et toutes une panoplie de fonctions pour manipuler le DOM, communiquer avec le serveur, réaliser des animations...
• Les modèles Closure : Google fournit un compilateur (sous la forme d'une archive JAR) qui prend en entrée des fichiers modèles (ou templates si vous préférez) portant une extension .soy et qui génère des scripts .js. Ces scripts peuvent ensuite être utilisé pour générer du HTML.

Ca doit être une erreur qui n'arrive pas souvent pour encore se trainer avec un logo du siècle dernier...

Vous avez une jolie application Web et vous souhaitez fournir une API ? Rien de plus simple avec Zend_Json_Server. Ce composant du Zend Framework permet de mettre en place une API utilisant le protocole JSON-RPC.

Ca fait un moment que je n'ai pas blogué, je vais me rattraper avec un petit tutoriel sur Zend_Navigation. Je vous propose de réaliser un menu à deux niveaux similaire à celui qu'on trouve par exemple sur le site de Libération, le javascript en moins.

Très intéressante vidéo sur la conception des interfaces utilisateur par Ryan Singer, Web Designer chez 37signals (Basecamp) :

• Tout baser sur un modèle
• Être explicite et utiliser beaucoup de texte
• Décomposer les écrans avec les conventions REST
• Utiliser les contrastes pour matérialiser les priorités à l'écran
• Décomposer les actions en 3 parties (début: à quel endroit l'action est initiée, milieu : comment l'action se déroule, fin : à quel endroit se rend-t'on à la fin de l'action et quelles sont les informations à afficher)
• Garder les templates simples et les concevoir de façon à ce qu'ils révèlent leur utilité

UI Fundamentals for Programmers by Ryan Singer from ChicagoRuby on Vimeo.

La suite de mes aventures avec la base de données Mongo (l'épisode 1, : c'est ici).

Voilà ce qu'on trouve dans leur FAQ (http://delicious.com/help/faq#install):

Mongo DB est une base de donnée orientée documents. A la différence des bases de données traditionnelles qui stockent leurs données dans des tables, Mongo DB utilise des collections d'objet (au format JSON). L'avantage de cette disposition, c'est que les colonnes n'ont pas à être fixées à l'avance et que chaque objet dans une collection peut avoir ses propres colonnes. Une base Mongo DB ne nécessite donc pas de schéma.

Ce week-end je m'apprêtait à développer un système de plugin pour Zend_Db_Table quand j'ai eu la présence d'esprit de consulter la feuille de route du ZF (http://framework.zend.com/roadmap). Bien m'en a pris car ce composant est justement prévu pour la prochaine version du framework (1.10). Il a même failli être intégré à la 1.9.