• Javascript forms validation.Powerful, UX aware & Dead simple.
• Make the Web Faster — Google Developers
• stackoverflow – Determining a page is outdated on github pages
• Firebug Tip : include() command
• Front-end performance for web designers and front-end developers
• Javascript forms validation.Powerful, UX aware & Dead simple.
• Important Considerations When Building Single Page Web Apps
• Talking RequireJS at TakeOff Conf
• [FR] 10 Bonnes Pratiques JavaScript
• ES6 : My Favorite Parts
• AngularJS: the beauty of concision
• Storing images and files in IndexedDB
• Why Javascript?

Misc

• alias.sh Featured Aliases
• Announcing the Firefox OS Developer Preview Phone!
• Establishing An Open Device Lab
• Advice for new and aspiring technical speakers
• [FR] Développeurs seniors. Pourquoi ? Comment ?
• Key points to look for in your next job if you are a developer

The downsides are :

• I put aside too many items
• I often forgot to check out my reading list on Pocket
• Pocket doesn’t provide a easy way share a bunch of links
• I don’t want to save those on Pocket without a backup somewhere else

For some time now, I looking for a way to force myself to check this list on a regular basis. Moreover, even if IFTTT allows me to perform automatic backup of the bookmarks, no one but me can take advantage of this list.

Starting today, I am launching a new series of articles entitled “Reading List”. As its name obviously suggests, each article will bring together a few links to sites, articles, resources that have caught my attention on the web during the past few days.

I plan to publish these posts on a weekly basis but it could be less depending on the volume I’ll collect every week. I hope some of you will find this useful. Do not hesitate to tell me your thoughts about this in the comments below.

As the process is mostly automated using IFTTT, Dropbox and a few scripts, I’ll also think about explaining it in a upcoming article.

Bon, d’accord, j’exagère un peu. C’est bien moins grave que ça en a l’air mais cette prise à partie m’a tellement surpris que j’en écris un article à chaud.

Oh, je m’en remettrais, hein! Ne vous en faites pas ;)

Un peu de contexte

Voici donc le tweet initial, celui qui a attiré mon attention et m’a fait réagir :

@____ @________ de ce côté tu seras pas déçu, y a *rien* de fait pour le blogging ;) quelques hooks plus tard je vous dirai des news ^^

Et voilà ma réponse :

@_______ @____ @________ Pas sur d’avoir tout le contexte, mais http://octopress.org/ ? non?

Ça semble anodin comme ça…

En intervenant dans cette conversation, mon intention était avant tout d’apporter mon aide éventuelle et d’en apprendre plus sur des outils que je peux être amené à utiliser. Mon erreur est sans doute d’avoir donné mon avis sans connaître le contexte complet de la conversation, ni même les participants. Mais après tout, le propre d’une conversation sur un media public, c’est bien qu’elle est ouverte à tout le monde, non? Pour avoir suivie celle-ci jusqu’au bout, il est évident maintenant que mon intervention était hors sujet et que je manquais d’éléments pour fournir un point de vue pertinent; pour autant, ça ne justifie pas le ton agressif de certaines des réponses que j’ai reçu.

L’objectif de ce billet n’est pas de commenter l’intégralité de la conversation, ni même de justifier mes arguments au cours de celle-ci ou encore d’accuser qui que ce soit, mais plutôt de présenter mon ressenti à la lecture de certaines des réponses que l’on m’a adressé.

Principes de base

Lorsque je m’adresse à quelqu’un, que ce soit dans la vie réelle, sur Internet, en privé ou en public, je fais de mon mieux pour rester respectueux et poli, et j’attends de mes interlocuteurs qu’ils en fassent de même. C’est la base de relations sociales saines et constructives. À partir de là, on peut discuter normalement. À partir de là, chacun peut avoir une opinion différente, exposer son point de vue, se tromper, convaincre ou rester sur ses positions.

Je crois avoir respecté ces principes de base ici aussi, et si malgré tout, certains de mes propos ont étés mal compris je m’en excuse. Certaines des réponses que j’ai reçu, en revanche, m’ont paru aller bien au delà de ces principes. Ça reste un ressenti personnel, j’aurai peut-être réagi différemment à un autre moment et je aussi pense que le format en 140 caractères imposé par Twitter contribue à amplifier cette impression, mais j’ai sérieusement vécu ce moment comme une agression. Je ne suis même pas certain que tous les autres participants aient pris conscience de la tournure déplacée de certains propos.

En écrivant ce billet, mon intention n’est pas de viser quelqu’un en particulier. J’avais simplement besoin de poser ça par écrit. D’abord pour me rappeler ces quelques minutes, et aussi en espérant que les rares lecteurs qui me liront s’en souviendrons lors de leurs discussions futures, en ligne ou non.

Pour finir

…si je peux me permettre un conseil qui vaut ce qu’il vaut:

Démarrer une conversation sur un media public implique que tout le monde peut y participer. Dans ce contexte, même si chacun est en droit d’estimer qu’un point de vue manque de pertinence, je ne vois pas ce qui justifie le fait d’exprimer son désaccord de façon agressive ou irrespectueuse. Si vous ne souhaitez voir personne d’autre intervenir, mentionnez le clairement ou mieux, utilisez un autre moyen de communication, privé de préférence.

Et puis, quand on parle de technos Web là, ça devrait rester fun, non?

PS : Pour ceux qui ont participé à la conversation dont il est question ici, s’ils vous arrivait de lire ce texte, sachez que je suis tout à fait disposé à discuter de l’usage et de la pertinence ou non d’octopress comme engine de blog, tant que ça n’a pas lieu en 140 caractères et que le ton reste amical.

You’ll find the slides bellow. The first part mostly present Grunt and why I think it’s a game-changer for front-end developers. As I already wrote about this in my previous post about Grunt, I invite you to read it if it sounds interesting to you. In the second part, I focused on showing a few examples use cases and concrete examples. That’s what I’m going to detail in this post.

Automating your web application

Bringing some automation to your web-application is probably the first thing you’ll try with Grunt. After all, that’s its first purpose, why it was designed for.

Because nothing worth an example, I reused an old project to illustrate this case. It’s a simple Gallery application build over Backbone.JS, jQuery, QUnit and Twitter Bootstrap. The full project is available on Github. The code I used as an example lives in the master branch. The original code, as it was before adding Grunt, lives in the before-grunt branch.

Adding Grunt to an existing project

Assuming Grunt is already installed on your system, adding Grunt to your project is as simple as typing the following in your terminal:

1
2

> cd /path/to/your/project/
> grunt init:gruntfile

After answering a few question, this will produce a single grunt.js file in your project’s folder. The basic structure of a gruntfile is looks like this:

1
2
3
4
5
6
7
8
9
10
11
12

/*global module:false*/
module.exports = function(grunt) {

  // Project configuration.
  grunt.initConfig({
    // ...
    taskName: {
      // task properties
    },
    // ...
  });
};

We are working with a web-application, so most of the tasks we need are already included in grunt. What do we basically need ?

• lint javascript files
• run qunit unit tests
• concat and minify javascript files

In addition, it would be interesting to:

• run qunit tests again on the minified js files to check if anything is broken in the process
• copy assets (css, pictures, etc.) to a build folder in order to have a standalone built version of the application
• create an alternative version of the html files containing minified js files rather than development files

Setting up your tasks

Lint, QUnit, concatenation and minification tasks are already built in Grunt. It won’t be too difficult to define these for our project. If you need another task, start by searching if an existing grunt-plugin have already been created by the community. You can search for an existing plugin on grunt homepage or directly with npm:

1
2

# Search for a grunt plugin to do some magic:
> npm search gruntplugin 'do magic'

Otherwise, you can define your own task using the Grunt API, but unless you need something very specific, I doubt you had to go there. Seriously, there are already 190 existing plugins at the time I write these lines.

Once you’ve found and installed the plugin you need, you still have to made it available in your gruntfile by using the loadNpmTasks api. In our case, we’ll need two external tasks:

1
2
3
4

  // ...
  grunt.loadNpmTasks('grunt-contrib-copy');
  grunt.loadNpmTasks('grunt-targethtml');
  // ...

From there, we just need to configure our tasks. I’m not going to detail every single line in the resulting gruntfile bellow. Basically, it allows us to build (lint, concat and minify) javascript files, copy any other files to a dist folder, and run the tests on both dev and dist files. The syntax is quite self-explaining and you can always refer to the official documentation is needed.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129

/*global module:false*/
module.exports = function(grunt) {

  // Project configuration.
  grunt.initConfig({

    // read some data from package.json file
    pkg: '<json:package.json>',
    // Defines project's meta data
    // the banner is used by minification task and 
    // will be at the beginning of each processed file
    meta: {
      banner: '/*! <%= pkg.title || pkg.name %> - v<%= pkg.version %> - ' +
        '<%= grunt.template.today("yyyy-mm-dd") %>\n' +
        '<%= pkg.homepage ? "* " + pkg.homepage + "\n" : "" %>' +
        '* Copyright (c) <%= grunt.template.today("yyyy") %> <%= pkg.author.name %>;' +
        ' Licensed <%= _.pluck(pkg.licenses, "type").join(", ") %> */'
    },
    // Defines a custom config property.
    // This property '<%= build.dest %>'
    build: {
      dest: 'dist'
    },
    // lint task
    // Defines witch files to lint
    lint: {
      files: ['grunt.js', 'js/gallery/**/*.js', 'tests/js/**/*.js']
    },
    // qunit multi-task
    // Defines 2 different targets
    // (dev, dist) for running qunit.
    // Each target defines a list of test files
    qunit: {
      dev: ['tests/index.html'],
      dist: ['<%= build.dest %>/tests/index.html']
    },
    // concat multi-task
    // Defines 3 different targets 
    // (libs, tests, dist) for concatenation.
    // Each target defines a list of files to concatenate
    // and a destination file to write the output
    concat: {
      libs: {
        src: [ "js/libs/json2.js", "js/libs/jquery-1.8.2.min.js", "js/libs/mustache-0.7.js", "js/libs/underscore-1.4.1.min.js", "js/libs/backbone-0.9.2.min.js" ],
        dest: '<%= build.dest %>/js/libs/<%= pkg.name %>-libs.<%= pkg.version %>.js'
      },
      tests: {
        src: [
          '<banner:meta.banner>', 'js/gallery/config.js', 'js/gallery/models/gallery.js', 'js/gallery/views/header.js', 'js/gallery/views/main-image.js', 'js/gallery/views/thumbnails.js', 'js/gallery/views/gallery.js' ],
        dest: '<%= build.dest %>/tests/js/<%= pkg.name %>-tests.<%= pkg.version %>.js'
      },
      dist: {
        src: [
          '<banner:meta.banner>', 'js/gallery/config.js', 'js/gallery/models/gallery.js', 'js/gallery/views/header.js', 'js/gallery/views/main-image.js', 'js/gallery/views/thumbnails.js', 'js/gallery/views/gallery.js', 'js/gallery/app.js' ],
        dest: '<%= build.dest %>/js/<%= pkg.name %>-app.<%= pkg.version %>.js'
      }
    },
    // min multi-task
    // Defines 3 different targets 
    // (libs, tests, dist) for minification.
    // Each target defines a list of files to minify
    // and a destination file to write the output
    min: {
      libs: {
        src: ['<config:concat.libs.dest>'],
        dest: '<%= build.dest %>/js/libs/<%= pkg.name %>-libs.<%= pkg.version %>.min.js'
      },
      tests: {
        src: ['<banner:meta.banner>', '<config:concat.tests.dest>'],
        dest: '<%= build.dest %>/tests/js/<%= pkg.name %>-tests.<%= pkg.version %>.min.js'
      },
      dist: {
        src: ['<banner:meta.banner>', '<config:concat.dist.dest>'],
        dest: '<%= build.dest %>/js/<%= pkg.name %>-app.<%= pkg.version %>.min.js'
      }
    },
    // targethtml multi-task
    // Defines 2 different targets (release, tests) 
    // Each target defines a source file to process
    // and a destination file to write the output
    targethtml: {
      release: {
        src: 'index.html',
        dest: '<%= build.dest %>/index.html'
      },
      tests: {
        src: 'tests/index.html',
        dest: '<%= build.dest %>/tests/index.html'
      }
    },
    // copy multi-task
    // Defines 1 single target (dist) 
    // copy files from development path 
    // to 'build.dest' folder
    copy: {
      dist: {
        files: {
          "<%= build.dest %>/css/": "css/**",
          "<%= build.dest %>/img/gallery/": "img/gallery/**",
          "<%= build.dest %>/js/libs/bootstrap/": "js/libs/bootstrap/**",
          "<%= build.dest %>/tests/": ["tests/js/**", "tests/libs/**"],
          "<%= build.dest %>/gallery_data.json": "gallery_data.json"
        }
      }
    },
    // clean task
    // remove every file from the defined folders
    clean: ["<%= build.dest %>"],

    // watch task
    // runs the defined tasks every time a watched file is updated
    watch: {
      files: '<config:lint.files>',
      tasks: 'lint qunit:dev'
    },
    // ...
  });

  // Load external tasks (grunt plugins)
  grunt.loadNpmTasks('grunt-contrib-clean');
  grunt.loadNpmTasks('grunt-contrib-copy');
  grunt.loadNpmTasks('grunt-targethtml');

  // Register custom tasks (alias tasks)
  grunt.registerTask('build', 'concat min targethtml copy');
  grunt.registerTask('clean-build', 'clean concat min targethtml copy');
  // Default task.
  grunt.registerTask('default', 'lint qunit:dev build qunit:dist');
};

Each task can be run independently by typing grunt taskName in a terminal. Additionally, you can run a specific target on every multi-task by typing grunt multiTaskName:targetName. The registerTask API allows us to define aliases to run a few tasks with a single command.

1
2
3
4
5
6
7
8
9
10
11
12
13
14

# run lint task
> grunt lint

# run concat and minify tasks
> grunt concat min

# run only dev target of qunit task
> grunt qunit:dev

# run "build" alias (ie: 'grunt concat min targethtml copy')
> grunt build

# run default task (ie: 'grunt lint qunit:dev build qunit:dist')
> grunt

So what’s next?

I hope you already see the kind of benefits you can get by adding Grunt to your web-application projects.

I also encourage you to take a look at the plugin system, which will allow you to create your own tasks. The well made gruntplugin init task (grunt init:gruntplugin) will bootstrap everything you need to start your own task and publish it in minutes. If you find yourself stucked at some point, the Grunt API documentation is a very good reference. You can also check the source code of one of the official plugins on github.

As I wrote at the beginning of this post, using Grunt to automate some tasks in your web-application projects is probably the first thing you’re going to try. But I’m convinced you can use it in many other ways. If you need some more examples, I invite you to look at my own experiments with Grunt:

• static-templater: A grunt-based command line tool to render HMTL and PDF from JSON and HTML templates
• grunt-wkhtmltopdf: A simple Grunt multitask that uses wkhtmltopdf to convert HTML files to PDF.

You probably already heard about grunt, don’t you? In case you don’t (seriously?), it’s been created by Ben Alman (aka. cowboy). I guess the best description is the one from the official home page:

Grunt is a task-based command line build tool for JavaScript projects.

OK, looks nice. But what’s new? I already have tools to lint or minify my Javascript. I already use qunit to unit test my code. And so on… Why should I use grunt instead of all these tools?

Here is why:

1. Because you probably don’t really use all these tools. I mean, for sure you know about them, and you already give them a try; but most people I worked with (including me) just don’t use them on real projects, in their day to day work, because bringing the pieces together is not that easy.
2. Grunt also uses the exact same tools you already know, or in the worst case, it can learn to use them. It doesn’t reinvent anything but allows you to organize your workflow in an uniform, yet flexible, way.

Do we need such a tool?

As a front-end developer, automation wasn’t really part of my workflow. My first job was in some king of web agency were every desktop machine ran on Windows XP, and our main development tools were Dreamweaver MX (I guess I’m getting old…) and Filezilla. At the time we would never have considered automation, unit testing or continuous integration.

Then I left that company and found a real engineer job. But still, like many other developers, I relied on some kind of heavy IDE where every low level interaction with the OS tend to be hidden. And I never really felt a need to dig into this. Until recently, I was convinced automation was only a concern for back-end or system engineers.

Everything you need is a terminal!

On the other hand, a lot of front-end tools came up recently, especially since Node.js brought Javascript to the Terminal but not only. Uglify-js, JSLint, Qunit, Jasmine, CoffeeScript, SASS, LESS are only the most famous but there are many others. These tools are changing our approach to front-end technologies, they make us more productive, adding value to our jobs.

But those tools remains command line tools. Even if each one of them is pretty simple to setup and use, combining all of these to make something adapted to a particular project can quickly become a nightmare for someone who’s not familiar with his Terminal. From my experience, a lot of front-end developers, especially younger ones, are not familiar with Bash scripting (and sometimes are afraid of it). For sure, that’s probably a bad approach, but that’s how I felt not that long ago and I’m pretty sure I’m not the only one in that case.

Grails developers write their scripts in Groovy. Rails developers have Rake files. We know how to write Javascript! That’s where we are comfortable and productive. We don’t want to get a headache by writing some messy bash script ^[1].

Here comes grunt

That’s what grunt does. It allows you to define a bunch of tasks, in a consistent way, by writing Javascript. Consistent is an important word here because you could probably achieve the same goal directly with Node.js but grunt gives you a simple way to write and organize your tasks. The most common ones (lint, concat, minify, test, etc.) are already included in the package so you don’t have to think about how to deal with them.

It also came with a really simple plugin system based on npm. If you find yourself needing to do something not included as a build-in task, try to search npm to see if somebody else has not already released a plugin that fits your needs. Otherwise, you can still write your own plugin and publish it to npm. The grunt API allows you to do pretty much everything you could need. And thanks to the built-in project scaffolding, it only takes a few minutes to change your spaghetti code into a well written plugin. Once here, publishing to npm is just a command line away so do not hesitate.

What’s next?

I hope you will give a try to grunt. Even more because something called Yeoman is getting close to the public release. I asked for a beta invite on twitter but for now, I didn’t have a chance to try it yet. It seems that it can do many more and as it’s based on grunt, among many others, it’s probably a good idea to get familiar with that one as soon as possible.

[1]: I actually did a lot of bash scripting recently and, believe it or not, I liked it. I wouldn’t have said that a few years ago. It’s a powerful programming tool and every developer should be comfortable with it. You’re not? Learn some basics. ;)

Du 10 au 12 Août dernier, j’ai participé au premier Riviera Coding Week-end, organisé par les membres du RivieraGUG avec la participation du JSSophia dont je fais partie. À ma connaissance, c’est le premier événement du genre qui ait lieu sur la côte d’azur. C’est en tout cas le premier auquel j’ai eu l’occasion de participer. Après ces 48 heures passées à construire, échanger, mais surtout coder, un petit bilan me semble bien utile.

Un Coding Week-End, quelle idée…

D’abord initié par le Groovy & Grails User Group , l’événement avait pour objectif de construire un site dédié pour le groupe. Par la suite, alors que certains membres du Javascript User Group ont aussi souhaité participer au week-end, la thématique de l’événement a un peu changée, pour s’axer d’avantage sur la collaboration entre les communautés locales.

Nous y voilà, c’est Vendredi soir, il est un peu plus de 19h30 lorsque j’arrive aux Satellites (qui nous ont hébergés gracieusement tout le week-end). La plupart des participants sont déjà arrivés. Il y a quelques visages bien connus, des collègues de travail, avec qui je passe déjà mes journées en semaines; certains sont simplement familiers, croisés lors des précédentes réunions du JSSophia ou lors de conférences qui ont eu lieu à Sophia-Antipolis quelques mois plus tôt; puis d’autres, enfin, que je rencontre pour la première fois.

D’entrée de jeu, l’ambiance est décontractée, l’accueil chaleureux et tout le monde est souriant. Sans trop savoir ce que va donner cette expérience, on sait déjà qu’on est tous là pour la même chose: partager notre passion du web et construire quelque chose, tous ensemble, just for fun.

Entrée en matière

| Loading Grails 2.1.0

Le programme du Week-end est assez simple et couvre principalement la soirée du vendredi, après tout, on est pas là pour subir un planning rigoureux.

Le début de soirée est assez calme. On fait connaissance, on se raconte nos vacances (pour ceux qui en ont pris…), on prends l’apéro en terrasse, on envoie quelques tweets en espérant ramener de nouveaux participants de dernière minute. Certains configurent le Raspberry Pi qui hébergera un EtherPad pour la durée du week-end.

Grails Crash Course

| Configuring classpath

Après avoir dévoré quelques pizzas, on attaque les choses sérieuses avec un Crash Course Grails d’une petite demi-heure présenté par Bertrand Goetzmann, bien utile pour ceux qui n’auraient jamais eu l’occasion d’utiliser le Framework. Là encore, l’ambiance est bien loin d’un cours magistral. La plupart des participants connaissent bien les rouages de Grails et le cours de Bertrand devient un bon prétexte pour partager les expériences de chacun et échanger les points de vue.

Brainstorming

| Environment set to development

Presque deux heures plus tard (la demi-heure la plus longue qu’on ai connu), nous démarrons un Brainstorming animé avec un objectif simple : qu’allons nous construire pendant le week-end?

Rapidement, quelques sujets intéressants font surface, souvent liés à l’activité des User Groups autour de Sophia-Antipolis :

• Manque d’activité des communautés : Il y a bien quelques user groups plus ou moins actifs mais la plupart restent globalement peu connus.
• Manque de relations et de collaboration entre ces groupes.
• Problématiques récurrentes d’un groupe à l’autre: trouver une salle, un sponsor, se faire connaître localement, informer et impliquer les membres

Vient ensuite l’idée de créer un site dédié aux User Groups de la région, ayant pour objectif de faciliter la découverte des communautés locales et leur collaboration. Le projet est ambitieux, mais l’important est surtout de lancer une initiative. Pour pouvoir obtenir un résultat concret en un week-end, nous décidons de nous concentrer sur les éléments de base du site et de garder de côté les idées qui demandent davantage de travail.

Première itération: Briques de base

• Enregistrement des utilisateurs
• Création d’un groupe par un utilisateur
• Abonnement à un groupe existant par un utilisateur
• Publication d’éventements organisés par le groupe
• Publication d’articles (blog) par un groupe
• Présentation des sponsors d’un groupe
• Association de tags aux groupes, utilisateurs

Développements ultérieurs:

• Favoriser la mise en relations des groupes géographiquement proches
• Favoriser la découverte des groupes par les utilisateurs
• Favoriser la mise en commun des ressources (salles, sponsors, relations) des groupes

C’est un résumé un peu rapide, mais tous les détails sont en ligne grâce au Raspberry Minute

On est là pour coder, non?

| Packaging Grails application

Après avoir déterminé notre objectif pour le week-end, nous n’avions plus qu’à nous mettre au travail. Raconter les deux jours suivants en détail serait sans doute trop long et assez peu constructif.

L’important à retenir est sans doute que les contributions ont été nombreuses : écrire du code, décortiquer OAuth, dessiner des croquis d’IHM, mettre en place l’intégration continue (continious outage?), travailler le design de site, aider les débutants ou simplement mettre l’ambiance et remotiver les troupes; chacun a contribué au projet selon ses compétences et sa forme du moment.

Le résultat est là! Le projet est bien démarré, le code est disponible sur Github et une première version est déjà en ligne

Bilan

| Running Grails application

Concernant la soirée de vendredi, je crois qu’il aurait été judicieux d’attaquer le brainstorming avant le Crash Course Grails. Cela aurait permis d’entrer directement dans le vif du sujet et d’utiliser le cours pour construire les premiers éléments du projet. On aurait gagné un peu de temps, et tout le monde aurait été plus impliqué dans le cours.

Ensuite, comme je l’ai dis plus haut, le projet était sans doute trop ambitieux par rapport au temps à notre disposition. Il faut reconnaître que la version obtenue à l’issue du week-end est plus proche du prototype que d’une application de qualité professionnelle.

Malgré tout, en ce qui me concerne, cette expérience a été clairement positive. Une ambiance bien sympa, des locaux au top, et une belle brochette de passionnés qui se sont tous impliqués dans le projet comme si l’enjeu avait été important.

Et tant pis si le résultat n’a pas la qualité que nous aurions pu attendre. Après tout, l’initiative est lancée et le code est là, ouvert à tous, disponible sur Github. Il ne tiens qu’à nous de continuer à faire avancer ce projet, en y contribuant nous-même ou en motivant d’autres personnes à participer. Quelques pull requests de plus et on l’aura le site communautaire qu’on a imaginé tous ensemble vendredi dernier.

Y’a plus qu’à comme on dit… ;)

Remerciements

| Server running. Browse to http://ughub.cloudfoundry.com/

Quelques remerciements pour finir. D’abord parce que j’ai passé un excellent week-end, mais aussi parce que ce type d’initiative participe à créer cette dynamique locale qui nous tiens tous à cœur.

Merci, donc, aux membres du RiveraGUG pour avoir lancé l’initiative et géré l’organisation. Merci aux Satellites, et plus particulièrement à Nicolas, qui a accueilli notre petit groupe sans rien demander en retour. Vos locaux sont géniaux, si un jour je me met à mon compte, je sais déjà où établir mon QG ;) Merci aussi à nos deux sponsors, Avisto et Sopra Group pour avoir nous avoir permis de travailler le ventre plein.

Et merci enfin à tous ceux qui étaient présent et qui se sont impliqués au cours du week-end.

Quelques liens en vrac

• L’application sur cloud-foundry : UG-hub
• Le Code Source sur Github
• Quelques Photos
• Les participants sont aussi sur Twitter
• Update: Les slides de Bertrand sont maintenant disponibles

A few weeks ago, I implemented a small bookmarklet to apply google-code-prettify anywhere on the Web. I put the source code on Github and used the (awesome) Automatic Page Generator to quickly create a landing page to host my bookmarklet.

The generated page lives on the same repository, on a branch called gh-pages. At this point, my concern was the following: How could I include the bookmarklet link on gh-pages branch from the source code living on the master?

Basic (handmade™) workflow

In a first try, I could just copy/paste the minified source into an <a href="..."> link in my index.html. But what happens if I update the source? I’ll probably have to deal with that kind of work flow:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

grunt # lint, concat and minifies source
git add .
git commit -m "Probably improved something in there"

# copy content from dist/prettyprinter.min.js

git checkout gh-pages # checkout gh-pages branch

# paste code somewhere into index.html (without)

git add .
git commit -m "Updated landing page with latest bookmarklet version"

git checkout master # back to master branch

Rather boring, right? Totally agree! And that’s why I decided to dig a little further to see how I could automate this.

Automate the whole thing!

Avoiding copy / paste

Copy/paste a file from a branch to another may be acceptable if you do it only once. From there, it’s probably better to use the following:

1
2
3
4

git checkout gh-pages # checkout gh-pages branch

# add/update 'dist' directory from master branch
git checkout master -- dist

Updating HTML content

As mentioned earlier, I already used grunt.js to lint, concat and minify my source on the master branch. So I searched for a way to use grunt to update the HTML link. I quickly found grunt-replace, perfect fit for the job. I ended up with an HTML source file, with a placeholder for the bookmarklet:

1

<a href='@@bookmarklet'>Prettify</a>

And a simple grunt replace task, reading the minified source and generating an up-to-date index.html

1
2
3
4
5
6
7
8
9
10
11

  grunt.initConfig({
    replace: {
      dist: {
        src: ['src/index.html'],
        dest: '',
        variables: {
          bookmarklet: '<%= grunt.file.read(\'dist/prettyprinter.min.js\') %>'
        }
      }
    }
  });

Introducing Git Hooks

Basically, Git Hooks allow you to automatically run custom scripts at any step in your workflow. Hooks must be defined in the .git/hooks/ folder. Placeholder files are already created, giving a pretty good idea about what’s possible or not.

1
2
3
4
5
6
7
8
9
10
11

$ ls .git/hooks/
applypatch-msg.sample
commit-msg.sample
post-commit.sample
post-receive.sample
post-update.sample
pre-applypatch.sample
pre-commit.sample
pre-rebase.sample
prepare-commit-msg.sample
update.sample

You only need to remove the .sample extension to define a hook, then edit the script to create your own awesome automation.

Bringing the pieces together

In my case, I created a post-commit script. Right after every new commit on the master branch, this piece of code runs and does all the crappy work.

1
2
3
4
5
6
7
8
9
10
11
12
13
14

#!/bin/sh
echo "\n| [prettify bookmarklet post-commit hook]"
git checkout gh-pages

# Update bookmarklet script from master branch
git checkout master -- dist lib

# update index.html & commit changes
grunt replace
git add .
git commit -m "Regenerated index.html from master branch"

git checkout master
echo "| All Done -- Use 'git push --all' instead of 'git push origin master' to push changes"

As both master and gh-pages branches are modified, they both need to be pushed on the remote repository. I use git push --all, which is fine if you don’t have any other updated branch. Otherwise, you’ll need a specific push for each branch.

Going further

I’d like to find a way to stop the script if the commit doesn’t occur on the master branch, but I’m not sure how to do it…

I’ll probably also add a pre-commit hook to lint/concat/minify the source. Grunt.js already simplified this to a one liner, but I often forget to call it before committing changes.

(Grunt + Git Hooks) appears to be a nice couple with a huge time-saving potential. I’d like to have an opportunity to try it on a larger project and see how it goes.

References

• Easily keep gh-pages in sync with master by Lea Verou
• Github Pages Workflow by by Oli Studholme
• Git post-commit hook to keep master and gh-pages branch in sync

Last time, we created a Javascript component used to upload a file asynchronously on the server. It uses FormData and FileList APIs in modern browsers but also degrades gracefully with browsers that don’t support those APIs.

This time, I’ll explain how to handle the thumbnail associated to the file input field. It’s a good example to introduce loosely coupled modules, and to show some other uses of the feature detection technique.

As mentioned in the previous post, you can find the source code on Github: uploader-thumbnail.

Loosely Coupled Modules

If you never hear about loosely coupled module, I highly recommended you to read/watch the following:

• Nicholas Zakas’ talk on Scalable JavaScript Application Architecture [YouTube]
• Addy Osmani’s Patterns For Large-Scale JavaScript Application Architecture

Those links will give you a pretty good picture but to summarize briefly, the main concepts to keep in mind when you want to rely on a loosely coupled modules architecture is that you need to:

• Split your code into separate modules, obviously.
• Don’t allow a module to know about each-other.

How could you do that? Let’s try to illustrate the idea with our file upload form.

Creating modules

We will create three simple modules to complete our file upload form, each one related to a very simple functionality:

• 1st Module uploader: uploads a file
• 2nd Module remover: ask for deleting a previously uploaded file
• 3rd Module thumbnail: display a thumbnail

In the first part we have already build the first one. As the two other ones are quite easy to implement, I won’t detail every piece of code in this post. Feel free to look at the complete source if necessary. For now let’s see those two as black boxes that fits with our requirements.

Communication between modules: introducing the observer

The Observer Pattern

As mentioned before, our modules can’t reference each-other. In other words, in the uploader’s code, calling a method from the thumbnail object or referring to it in any other way is forbidden.

1
2

// uploader's inside code
thumbnail.display(picture) // <-- WRONG!

That’s why we need to introduce the observer component. Its role is to allow communication between modules. In other words, instead of talking directly to each-others, modules in your application will talk and listen to the observer.

There many different implementations of the observer pattern but it’s basically a component with 3 methods:

1
2
3
4
5
6
7
8
9
10
11

var observer = {
  publish: function( topic ) {
    // ...
  },
  subscribe: function ( topic, func ) {
    // ...
  },
  unsubscribe: function ( topic, func ) {
    // ...
  }
}

• observer.publish('some-topic', message): send a message on the topic ‘some-topic’
• observer.subscribe('some-topic', callbackFunc): starts listening messages on the topic ‘some-topic’. callbackFunc will be called every times a message is published on the topic, the message will be passed as a parameter.
• observer.publish('some-topic', callbackFunc): stops listening messages on the topics ‘some-topic’.

Using the observer

Back the the upload form, the implementation doesn’t change that much. You only need to pass the observer as parameter, and publish some events to notify the application

1

this.obs = options.observer || {publish:function(){}, subscribe:function(){}};

1
2
3
4
5
6
7
8
9

beforeUpload: function(file) {
  this.obs.publish('submit.uploader', this.fileId, file);
},

onUploadDone: function(data) {

  // ...
  this.obs.publish('uploaded.uploader', this.fileId, this.data);
}

On the other side, the thumbnail module need to listen to these events and to react to these in an appropriate way. In our case, when receiving a submit event, the thumbnail module should hide an existing image and display a load indicator. When receiving a uploaded event, it have to show the newly uploaded picture.

1
2
3
4
5
6
7
8
9
10
11
12

Thumbnail.prototype = {
  init: function() {
    // ...

    // Observe uploader events
    this.obs.subscribe('submit.uploader', $.proxy(this.onUploadStart, this));
    this.obs.subscribe('uploaded.uploader', $.proxy(this.onUploadDone, this));

    return this;
  },
  // ...
}

As you can see in the above code, both uploader and thumbnail module are not aware from each others, they only talk and listen to the observer.

Conclusion

• You mat decide to completely change some module implementation, as long as it sends the same messages to the observer, everything is fine.
• Every other module in your application can listen to observer. The thumbnail may not be the only piece of application interested in uploader events. That’s fine, the new module just need to subscribe the appropriate event.
• Last but not least, if some module appears to be broken, or if it doesn’t starts as expected, other modules won’t be much affected and your application is still working (even if some features are down).

You probably already know that all jQuery’s ajax methods implement Promise interface. That’s why we can use the pipe() method to queue the queries, as well as done() and fail() methods to track the queries’ progress.

Another interesting point is how CoffeeScript make the code clearer and easy to read. I particularly enjoyed using splats (...) to write the $.when(deferredObjs...) part on line 34. Speaking about code readability, it’s such an improvement compared to the $.when.apply($, deferredObjs) Javascript counterpart.

You can find a working sample on jsFiddle.

References

• jQuery’s Deferred objects
• Source code on gist
• Working sample on jsFiddle

I choose File Upload Form example because it’s standalone, frequently used and it can be improved by many ways with HTML5 APIs. It’s a good example to introduce some very important Javascript concepts:

1. Using feature detection for progressive enhancement
2. Using loosely coupled modules to architecture web applications.

This post focus on the first part of the talk. It presents the feature detection technique. I’ll cover the second part, loosely coupled modules, in another article.

If you’re in a hurry, or simply don’t want to read the whole post, you’ll find the slides embedded below and everything else on Github:

• The final uploader-thumbnail source code.
• The step by step demo I used during the talk.
• The slides.

The talk was in French so the slides are also written in French, even if it uses a lot of English keywords.

Initial Markup

The main idea in progressive enhancement is to provide an application that work in any context. A good approach is to start development with features that will work (quite) everywhere, and progressively add more specific features to improve your application’s user experience in modern browsers.

Talking about file upload form, our starting point is a simple HTML markup.

1
2
3
4
5
6
7
8

<form id="upload-form" action="" method="post" enctype="multipart/form-data">
  
  <label for="upload">Go Upload Something</label><br>

  <input type="hidden" name="fileId" value="12345">
  <input type="file" name="upload" id="upload" accept="image/*">
  <input type="submit" value="Upload">
</form>

It’s simple, works in every browser and, assuming the server behind do his job, it works without a single line of Javascript. On the other hand, it requires a full page reload so the first thing to do to bring some hype in this is to allow uploading the file with an asynchronous request.

Feature detection

Uploading a file trough an asynchronous request isn’t that easy. The FormData API perfectly fits our needs but it’s not well supported across all browsers (IE, I’m looking at you… See Browser_compatibility section).

Remember that our main concern is to provide the best user experience on each browser. So how do we upload a file asynchronously in a browser that don’t support FormData API? Answer is by using an iframe.

iframe file upload

Please note that I started by creating a jQuery plugin to make the code more easily reusable. I also hid the submit button and the bound event ‘onchange’ on the input field to submit the form. The following code snippets come from step1/upload.js file.

First, we have to listen to the submit event to prepare the form:

1
2
3
4
5
6

this.$form.on('submit.uploader', $.proxy(function(){

  // old-school iframe method
  this.prepareIframeUpload();
  return true; // submit the form
}, this));

Next, let’s append an hidden iframe to the form and define the target attribute to match the iframe id. Once done, the form can be submitted as usual, the server’s answer will be loaded into the iframe.

However, due to security concerns, we won’t be able to read the iframe content once loaded, so we also need to create a callback function and to send the function name to the server as a URL parameter. This way, the server script will be aware that we are using an iframe and will be able to generate the appropriate response.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

prepareIframeUpload: function() {

  var id, cb, iframe, url;

  // Generating a random id to identify
  // both the iframe and the callback function
  this.id = Math.floor(Math.random() * 1000);
  id = "uploader-frame-" + this.id;
  cb = "uploader-cb-" + this.id;

  // creating iframe and callback
  iframe = $('<iframe id="'+id+'" name="'+id+'" style="display:none;">');
  url = this.$form.attr('action');

  this.$form
      .attr('target', id)
      .append(iframe)
      .attr('action', url + '?iframe=' + cb);

  // defining callback
  window[cb] = $.proxy(function(data) {
      console.log('received callback:', data);

      // removing iframe
      iframe.remove();
      this.$form.removeAttr('target');

      // removing callback
      this.$form.attr('action', url);
      window[cb] = undefined;

      this.onUploadDone(data);
  }, this);
},

Knowing that the server response will be loaded as iframe content, the server script has to generate this small piece of HTML. It includes a script tag, witch calls the callback function on the parent window. The json result is send as a parameter of that function.

1
2
3

<script type="text/javascript">
window.top.window['<%- callback %>'](<%- result %>);
</script>

Here we are. Our script can send files asynchronously, without reloading the whole page, and it even works with old browsers. Of course, we could decide to stop there, but we won’t because of the following:

• No Error handling: if something goes wrong while sending the file, or if the server don’t render the good response, the callback function will never be called, and we can’t handle the error. You probably want to add a timeout to the script above to avoid waiting for an answer that would never come.
• It’s not AJAX. You probably already notice this point. We are faking it. The form is still sent as HTML form, we only changed his target. The file is uploaded asynchronously, but without any XmlHttpRequest involved.
• It’s dirty. I’m OK as it stays a fall-back solution, but keeping it as the main implementation? Yuck!

FormData file upload

Time to do things the right way? OK. Let’s start by editing the submit event listener as following:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

this.$form.on('submit.uploader', $.proxy(function(){

  var file = false
  if (this.$upload[0].files) file = this.$upload[0].files[0];

  this.beforeUpload(file);

  if (window.FormData && file ) {

      console.log('FormData supported and file is:', file);
      this.upload(file);
      return false;
  }
  // fallback to old-school iframe method
  else {
      console.log('FormData is not supported or file is undefined:', file);
      this.prepareIframeUpload();
      return true; // submit the form
  }

}, this));

The this.$upload variable represents a jQuery object containing the input[type=file] DOM node (see the complete step2/upload.js file for more details). Here we have to check if the browser supports both File and FormData APIs. If these two conditions are satisfied, we can go with the “HTML5” file upload. Otherwise, we just fall-back to the iframe hack… Simple isn’t it?

This is Feature Dectection and it’s one of the key concepts of modern web development. It’s the only way we have to use the latest HTML5 features without breaking old browser’s support.

Now, we’re sure that we can use FormData upload, we just need to implement the method as shown in the following code extract. As you can read, it’s way simpler and less hacky compared to the iframe method. Server response and errors are handled the same way than with any other ajax request.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

upload: function(file) {

  var formdata = new FormData(this.$form[0]);

  if (formdata) {
      var jqXhr = $.ajax({
          url: this.$form.attr('action'),
          type: this.$form.attr('method'),
          data: formdata,
          // tells jQuery not to prepare data before sending the request
          processData: false,
          contentType: false
      });

      jqXhr
          .done($.proxy(this.onUploadDone, this))
          .fail(function(){
              console.log("upload error:", arguments);
          });
  }
},

We’re done for part 1. Our upload form is fully functional for both modern and old browsers, and even with Javascript disabled. In the 2nd part, I explain how to handle the thumbnail associated to the file input field. It’s a very good example to introduce loosely coupled modules, and to show some other uses of the feature detection technique. File Upload Form – Part 2: Loosely Coupled Modules

References:

• Browser detection using the user agent on MDC
• FormData API
• FileList API

The pinger will ask the given URL every ‘interval’ minutes if it detects some activity by listening to the events listed in ‘listen’ parameter.

Have a look to the ‘defaults’ variable below for further details about available parameters and default values.

The code bellow is a starting point, it’s clearly inspired from the jQuery Doc. Just search/replace pluginName with your plugin name and go ahead with your own code.

Links Summary:

• jquery.plugin_name.coffee source code
• CoffeeScript
• jQuery Doc

Pour changer un peu des précédent articles dédiés au développement iPhone, je vais aujourd’hui présenter un petit outil Javascript, utilisant le Framework jQuery. Rien de révolutionnaire, c’est simplement un plugin jQuery permettant de dérouler un bandeau HTML au dessous d’un autre. J’ai appelé ce plugin ‘helpBox’ car ce widget est particulièrement adapté pour afficher une aide contextuelle.

Voici le code source.

Rien de bien compliqué ici si l’on connais déjà la structure d’un plugin jQuery. On commence par définir quelques paramètres…

1
2
3
4
5
6

var defaults = {
    helpContent:'<p>help content</p>',  // jQuery Selector or plain text HTML.
    contentCls:'help-content',          // CSS Class applied to the help box.
    buttonCls:'help-button',            // CSS Class applied to the help button.
    buttonText:'Help'                   // Help Button text
}

Ensuite, le plugin ‘helpBox’ se contente de recherche le code HTML du contenu de l’aide pour l’ajouter au document avec le bouton associé.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

return this.each( function() {

    var o = options

    // Gets help content
    var content = ( $(o.helpContent).size() > 0 ) ? $(o.helpContent).html() : o.helpContent;

    // Appends help box and help button
    $(this).append("<div class='"+o.contentCls+"'>" + content + "</div>")
        .append("<div class='"+o.buttonCls+"'><a href='#'>"+o.buttonText+"</a></div>");

    $(this).find('.'+o.contentCls).hide();

    // [...]
})

Ensuite, il ajoute deux gestionnaires d’événement au bouton: un ‘mouseover’ pour ouvrir le dialogue d’aide et un ‘click’ pour fermer ce dernier.

1
2
3
4
5
6
7
8

// Open the box on button mouseover, close it on click
$(this).find('.'+o.buttonCls+' a').mouseover( function() {

    $(this).parent().prev('.'+o.contentCls+':hidden').slideDown();
}).click( function() {

    $(this).parent().prev('.'+o.contentCls+':visible').slideUp();
});

Voilà tout. Facile non?

• Le code complet est ici: jquery.helpbox.js

Quelques ressources utiles pour finir:

• jQuery Plugin Authoring
• Les bases du développement de plugin jQuery sur learningjquery.com

Enjoy!

Pour les plus pressés, ça se passe ici:

ZBar: How to add a barcode reader to an iPhone app

Pour les autres, voilà un peu plus de détails:

Les QR Codes sont de plus en plus répandus dans les applications mobiles. Au détour d’un projet iPhone, vous pourriez être amenés, tout comme moi, à devoir décoder ces carrés “magiques”.

Si tel est votre cas, sachez que la tâche sera des plus simples grâce à l’excellent projet ZBar bar code reader. L’intégration du wrapper Objective-C de cette librairie m’a pris en tout en pour tout 10 minutes. De plus, le scan des codes est effectué à la volée (comprenez sans que l’utilisateur ait besoin de presser le bouton de l’appareil photo, dès que le code est dans le cadre). La documentation limpide fournie sur le wiki du projet transformera votre application en un lecteur de codes à rendre jaloux le caissier de l’hyper en bas de chez vous.

La doc est là:ZBar: How to add a barcode reader to an iPhone app. Dépêchez-vous, plus que 9’30…

Décoder des codes QR:

• L’application ZBar sur l’AppStore
• ZXing (prononcer “Zebra_Crossing”)

Générer des QR Codes en ligne:

• Générateur de QR Code
• QR Code Generator

Après le grand ménage sur le blog, plein d’enthousiasme, j’ai entrepris de rédiger un tutoriel détaillé à propos du développement d’un ImageViewer pour iPhone, avec une interface la plus proche possible de l’application Photos. Au cours de l’écriture de ce billet, j’ai constaté 2 choses:

• Tout d’abord, ça fait un billet sacrément long, à l’écriture comme à la lecture.
• Ensuite et surtout, j’ai constaté que l’intérêt était assez limité car l’exercice s’est révélé relativement simple.

En revanche, lors du développement de mon ImageViewer, il y a un aspect qui a attiré mon attention: l’extension d’un protocole. Ce point précis peut présenter une certaine difficulté pour peu qu’on n’y ai jamais été confronté et il m’a été assez difficile de trouver des exemples clair sur le web. J’ai donc décidé de rédiger un billet plus court, qui détaille la façon de dériver la classe UIScrollView tout en étendant le protocole UIScrollViewDelegate associé.

Si vous souhaitez, comme moi, reproduire l’interface de l’application Photos de votre iPhone, vous allez sans doute créer un UIScrollView afin de permettre à l’utilisateur de naviguer d’une image à l’autre. Pour ce faire, le projet “Scrolling” fourni en exemple dans la documentation d’Apple constitue un bon point de départ. La logique du scroll est contenue dans les méthodes viewDidLoad et layoutScrollImages du fichier MyViewController.m mais il vous faudra l’adapter un peu à votre cas d’utilisation.

En revanche, j’ai constaté que les événements de Touch n’étaient pas transmis par la UIScrollView. Gênant lorsque l’on veut ajouter des interactions en plus du scroll.

Pour capturer ces événements, qui ne sont pas transmis par la UIScrollView, la logique voudrait que l’on créé une classe qui étends la scrollView.

En surchargeant la méthode qui transmet les événements, on obtient ce qui suit:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

// TapScrollView.h
@interface TapScrollView : UIScrollView {
}
@end

// TapScrollView.m
#import "TapScrollView.h"

@implementation TapScrollView
- (void)touchesBegan:(NSSet *)touches withEvent:(UIEvent *)event {

  [self.delegate tap];
  [super touchesBegan:touches withEvent:event];
}
@end

À ce stade, il faut ajouter la méthode tap au protocole qui défini le delegate de notre TapScrollView. On procède en ajoutant la définition d’un nouveau protocole dans le fichier TapScrollView.h.

Ce protocole va étendre UIScrollViewDelegate afin que l’on puisse encore recevoir les événements de touch, comme suit:

1
2
3
4
5
6
7
8
9
10

// TapScrollView.h
@protocol TapScrollViewDelegate <UIScrollViewDelegate>

- (void) tap;

@end

@interface TapScrollView : UIScrollView {
}
@end

Si on en reste là, la propriété delegate reste celle défini par UIScrollView car nous ne l’avons pas surchargée. On peut donc supposer que celle-ci répond au protocole UIScrollViewDelegate, et non pas TapScrollViewDelegate comme on l’aurai souhaité. Dans ce cas, il suffit de surcharger la propriété delegate dans TapScrollView. Voilà le code obtenu:

1
2
3
4
5
6
7
8
9
10
11
12

// TapScrollView.h
@protocol TapScrollViewDelegate <UIScrollViewDelegate>

- (void) tap;

@end

@interface TapScrollView : UIScrollView {
  id<TapScrollViewDelegate> delegate;
}
@property (nonatomic, assign) id<TapScrollViewDelegate> delegate;
@end

Ok, on approche du but. TapScrollView réponds bien au protocole et la méthode tap sera correctement appelée elle-aussi. En revanche, les méthodes du protocole UIScrollViewDelegate ne sont plus appelés… On tourne en rond. J’ai mis pas mal de temps à trouver la solution. L’astuce consiste à surcharger aussi les accès à la propriété delegate, de façon à transmettre les appels dans les deux sens (UIScrollView vers TapScrollView et vice-versa). Voilà le code final:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

// TapScrollView.m
#import "TapScrollView.h"

@implementation TapScrollView

- (void)touchesBegan:(NSSet *)touches withEvent:(UIEvent *)event {
  [self.delegate tap];
  [super touchesBegan:touches withEvent:event];
}

- (id<TapScrollViewDelegate>) delegate {
  return (id<TapScrollViewDelegate>)super.delegate;
}

- (void) setDelegate :(id<TapScrollViewDelegate>) aDelegate {
  super.delegate = aDelegate;
}
@end

Vous voilà donc avec une ScrollView qui, en plus de capturer les événements relatifs au scroll, va transmettre les actions de votre choix. Ici, un simple tap, mais le principe reste valable pour des actions plus complexes.

Quelques liens utilies pour finir:

• Scrolling : un sample project de la documentation Apple
• UIScrollViewDelegate Protocol Reference: tout ce que fait le protocole associé aux UIScrollView (et ce qu’il ne fait pas)
• Protocols: la documentation iPhone sur les protocoles