Introduction¶

A propos du nom¶

Le préfixe afpy (prononcez eufpi en cht’i, et ofpi en bourgignon) est la marque de fabrique de l’Association Francophone Python.

Un bon produit Afpy est un produit qui utilise ce préfixe.

les ofpiro (je suis Dijonnais) en sont l’exemple-type.

Un framework web sans orientation particulière (CMS, GED, Site, ...) concocté à l’ofpy, doit donc s’appeler ofpyweb, ou afpyweb pour une sonorité un peu plus universelle.

Le site de l’Afpy¶

Après plusieurs années de bon et loyaux services, le site de l’Afpy a veilli et la technologie utilisée rendait sa maintenance et ses évolutions dépendantes de quelques personnes. Les contributions des membres interessées étaient freinées par le choix de Plone : tout le monde n’a pas la chance de maitriser cette plate-forme.

Il y a un an, Gael a basculé le planet sur une application Django (http://www.afpy.org/planet).

Ensuite, au cours de l’Afpy computer camp à Dijon (rural programming) des membres ont commencé à bosser sur d’autres applications périphériques, comme l’application Jobs (pas encore releasée) pour remplacer la section Jobs du site et faciliter la saisie et la gestion des annonces de type job sur le site.

Ces derniers mois, le mouvement s’est acceleré et de multitudes de projets périphériques sont en train d’être réalisés dans des technologies plus légères que Zope/Plone, avec l’idée de les réunir pour former le site.

Par exemple:

• Yap: un nouveau planet (oui on avait déjà feedjack en django mais celui-ci est plus cool et plus fun)
• PyBB: un forum excellent
• une instance de wiki moinmoin sur http://www.afpy.org/wiki
• etc.

Un frontal appelé maison est également en cours de conception et signe la fin prochaine du site en Plone, puisqu’il se chargera de la page d’accueil à sa place. Manqueront les news et le moteur de recherche.

Comment ca marche¶

Mise à part le frontal qui est encore en Plone. toutes ces applications sont orchestrées par un serveur Paste. Apache gère pour l’instant les redirections, sachant qu’à terme toutes les briques seront gérées par Paste.

Plone continue à servir la plupart des pages du site, et Paste se charge de servir un certain nombre de sous-applications.

Pour servir ces application, Paste:

• rajoute dans l’environnement les infos de connexion en allant les chercher sur le LDAP de l’association. (Flèche bleue ‘auth’ dans le schéma)
• appelle l’application sous-jacente dans cet environement
• habille (skinne) la page renvoyée par l’application avec un afpylook (Flèche bleue ‘skin’ dans le schéma)

C’est possible grâce à la norme WSGI, qui permet à Paste de piloter les applications web, du moment que celles-ci sont compatibles avec cette norme. Lisez http://www.wsgi.org/wsgi/

Frameworks Compatibles WSGI:

• Zope 3
• Pylons
• Django
• ...

Liste complète ici: http://www.wsgi.org/wsgi/Frameworks

Le gros interêt de cette architecture est de permettre à tout membre de l’association de participer aux développements sans avoir à subir la courbe d’apprentissage de Zope (Pylons est très vite maitrisé par exemple).

En terme d’organisation du site, chaque application gère un dossier racine:

• /membres = application de gestion des membres
• /planet = le planete
• / = maison
• etc..

Le fichier ini du serveur Paste se charge de faire ces correspondances. Ce fichier intercale également les middleware en charge d’ajouter les infos d’authentification et le skinning.

Un framework générique¶

Un site comme celui de l’Afpy au final sera composé:

• d’une configuration PasteDeploy qui défini dans son fichier ini les applications à utiliser
• d’un certains nombres d’applis
• d’un lot de middlewares en charge de skinner les applis avec la même garniture et de gérer l’auth

Alors pourquoi parler d’un framework générique ?

Il est possible de gérer d’autres sites web en changeant le skin et en variant les applications à utiliser. Il manque quelques briques stratégiques pour couvrir des uses cases généraux, en cours de développement ou à développer.

Le but du projet afpyweb est de fournir un ensemble cohérent de middleware WSGI, développés ou non dans le cadre de l’association, et une série d’application ou de services WSGI permettant de couvrir un spectre de fonctionnalités assez large.

Certaines briques sont très spécifiques comme la gestion des membres de l’asso ou le job board, mais d’autres peuvent être réutilisées. Une autre association pourrait d’ailleurs réutiliser directement le système complet pour créer son site communautaire et faire une gestion légère de ses membres.

Le schéma ci-dessous représente ce framework générique.

Livrables (Où est mon framework ?)¶

Finalement, l’application est composée de différentes applications et middlewares WSGI, et on ne peut pas vraiment parler d’un framework. Ces éléments sont réunis par le biais d’un fichier de configuration de Paste et l’ensemble est organisé en fonction des besoins.

Mais certaines briques mettent en place un environnement minimale pour une application web. L’afpy organise cet environnement avec zc.buildout, qui permet de décrire dans un fichier de configuration les briques à utiliser.

De plus, certains standards sont mis en place par les middlewares: où récuperer les infos de connexions, etc. Il est donc possible de définir un standard très léger, commun à toutes les applications et une mécanique de registry pour être en mesure de lister les briques disponibles.

Le framework est donc:

La connaissance des briques qui vont bien et comment les organiser dans un buildout.

Les livrables du projet afpyweb, hormis les briques en cours de conception seront donc:

• un squelette qui génére une configuration buildout, basé sur PasteScript, et qui utilise au minimum le système d’authentification, le système de skinning, et l’application frontale, et permet à l’utilisateur de choisir les briques, et les associer aux chemins.

  Des pré-configurations seront égalements proposées et régulièrement mise à jour et documentées:

  • site communautaire
  • site de news
  • planet
  • etc.

• un squelette d’application WSGI qui fournit des rails pour le développement de briques afpy.*;

• Un KGS (Known Good Set) qui répertorie dans la nébuleuse des applications et middlewares ceux qui peuvent être utilisées dans l’environnement. Ce KGS est capable d’interroger un service sur afpy.org, en XML-RPC et de lister les briques notés comme compatibles.

Les squelettes seront regroupés dans afpy.squelette, et le KGS sera une application WSGI nommée afpy.kgs, qui fourni une interface XML-RPC et un client pour l’interroger et pour injecter une brique dans la configuration existante.

Au final, un développeur sera en mesure de générer une configuration la plus proche possible de son besoin, de consulter le KGS pour en ajouter d’autres, puis de créer des briques si besoin.

Exemple de session:

$ paster create -t afpyweb_site monsite
$ cd afpyweb_site
$ paster create -t afpyweb_app mon_app
$ afpy_kgs --list-middlewares
afpy.skin   Système de skinning
afpy.auth   Authentification
Beaker      Caching
...
Zozo        Middleware bizzare

$ afpy_kgs afpy.skin --info
Système de skinning, fourni dans le squelette de base.

Permet de gérer une CSS, un footer et un header commun à toutes les applications.
$ apfy_kgs Yap --info
Planet super cool

$ afpy_kgs --inject Yap
Yap injecté dans buildout.cfg