Proposition et préparation

Il y a deux moments importants lorsque vous choisissez de participer :

• le moment où vous choisissez le contenu de votre intervention ;
• le moment où vous choisissez la manière de le présenter.

Le contenu fait partie de vous, de votre expérience, de votre passion. C'est de l'acquis et il va donc falloir faire un effort de concision et de pertinence. C'est difficile mais nécessaire. Normalement au moment où vous faites votre proposition c'est déjà bouclé (d'où le travail en amont et le secret espoir qu'il n'ait pas été inutile !), au moins dans les grandes lignes.

Reste le format. Malheureusement, c'est souvent imposé et trop long. Il n'y a qu'à regarder TED qui est une référence en la matière : pas plus de 20 minutes. C'est le seul moyen de garder l'attention du public et d'être pertinent. Au-delà ça devient un tutoriel avec des lignes de codes ou alors ça part dans des explications trop avancées pour la moitié de la salle. J'ai fait ces erreurs, et je ne les souhaite à personne ;-).

D'une manière plus générale, trop peu de temps est alloué aux "entractes" qui sont aussi importantes et intéressantes que les conférences elles-mêmes. C'est bien dommage. Les barcamps évitent cela mais il serait peut-être intéressant de trouver un juste milieu. Le Lift Marseille a l'air d'éviter ça d'après le programme.

Pour ce qui est de la préparation, je suis persuadé qu'il est important d'essayer de faire une pré-présentation mais pour cela il faut un auditoire pertinent (sinon je n'y arrive vraiment pas), et ça c'est malheureusement très difficile à trouver...

Interactivité et discussions

Beaucoup ont été surpris de me voir me ruer sur twitter à la fin de mon intervention lors de Paris Web. Je n'en ai pas reparlé mais à la base je voulais afficher les résultats de la recherche pendant les questions pour pouvoir interagir directement avec les plus timides. À la réflexion, j'aurais aimé avoir le fil des commentaires en live pendant mon intervention aussi. Je pense à twitter mais un simple curseur (anonyme) permettant de voir si on arrive à transmettre le bon message serait vraiment utile. Ça permettrait de mettre en confiance ou de redresser la barre si nécessaire. Voire d'arrêter si l'on se rend compte que l'on ne s'adresse pas au bon public.

Un autre point qui est toujours assez délicat lors d'une intervention c'est le passage aux questions. Impossible de savoir s'il va y en avoir trop, pas assez, pas du tout, il manque ici aussi un outil permettant de faire remonter les questions pertinentes et d'estimer avant la fin s'il faut consacrer une large par aux questions ou pas.

Est-ce que ces outils seraient sources de distraction ? Bien entendu mais bon, lors d'une conf de geek la moitié de l'audience a déjà un laptop sur les genoux et l'autre prend des photos en tweetant de son téléphone donc bon :-).

Si la conférence permet de donner une première approche sur un sujet, il serait très intéressant que la discussion se poursuive. Bien sûr il y a les questions personnelles à la fin mais ça ne concerne qu'une poignée de personnes alors qu'il y aurait matière à discuter entre tous les auditeurs autour de la problématique abordée. Quels moyens proposer pour poursuive la discussion ?

Partage et expérience

Qu'est-ce qui fait préférer une conférence plutôt qu'un livre ou un article sur le net ? Au-delà du charisme, c'est l'expérience de l'orateur qu'il vient partager. Je me fous de savoir qu'il faut lancer telle et telle commande pour arriver à ça. En revanche si l'auteur a eu ce problème et l'a résolu après avoir tenté ça puis ça, là ça m'intéresse. Un public a besoin qu'on lui raconte une histoire, toujours.

Seth Godin définit deux éléments permettant d'être un bon orateur :

1. Respect (de l'auditoire)
2. Amour (pour l'auditoire)

C'est exactement ça. En bonus, quelques conseils pertinents et pleins de bon sens.

Mise en application

J'aurais la chance de pouvoir mettre en pratique au moins une partie de ces conseils lors d'EuroDjangoCon à Prague du 4 au 8 mai puisque j'y organise un panel autour d'Open Stack et de ses implémentations dans Django. Ça sera une première pour moi de m'exprimer en anglais et ça va être difficile car j'ai un niveau vraiment moyen mais il faut de toute façon que je m'y mette sérieusement car ça me frustre souvent.

J'ai aussi soumis pas mal de propositions pour Pyconfr qui se tiendra les 30-31 mai et je me réjouis de voir qu'une partie de ces réflexions sur lesquelles je cogite depuis un moment ont été mises en pratique via les choix de formats et les durées proposées par les organisateurs.

Au plaisir de vous y retrouver. :-)

Mieux vaut tard que jamais.

Dans cette partie on va :

- configurer le fichier content/configure.zcml
- créer un profil

et puis je pense que ca suffira.

Une petite mise en bouche

Dans content/configure.zcml on va définir les permissions sur nos classes :

Pas compliqué.
Tout le monde poura accéder aux méthodes&attributs de l'interface IDossierHistoire qu'implémente DossierHistoire, alors que pour les  éditer il faudra avoir un certain droit.
Et c'est pareil pour Histoire.

Voilà, voilà c'est terminé pour le dossier content.

Maintenant il faut l'inclure dans jesuisunconnard.metier , pour cela il suffit  de rajouter une ligne dans le configure.zcml principal (jesuisunconnard.metier/jesuisunconnard/metier/configure.zcml) ; ce qui donne :

À  noter que dans la balise registerPackage, j ai enlevé  l'attribut initialize, vu qu'il nous sert à rien pour le moment.

Le plat de résistance

Souvenez-vous, dans la partie 2, on déclarait un type pour chacune de nos 2 classes.
Et je disais justement, qu'il faudrait les définir via des fichiers .xml, et bah ya plus qu'à!  
Je vous préviens va falloir résister à la tentation de dormir, sinon je ne vous délivrerai pas de votre ignorance. AMEN.

On va devoir créer nos fichiers .xml  dans un profil.
Or jesuisunconnard.metier n'en a pas, donc on en crée un.

Fichier jesuisunconnard.metier/jesuisunconnard/metier/configure.zcml :

puis il faut créer les dossiers :

Je ne ré-explique pas  à quoi ca sert un profil, cf partie 1.
Voilà la base est faite.

Pour définir nos types/objets, il faut d'abord les enregistrer :
nouveau fichier profiles/default/types.xml :

C'est la meme logique que pour le .xml de la partie 1 :
on sélectionne notre objet portal_types et on va y enregistrer nos 2 nouveaux types :
les objets DossierHistoire  et Histoire (ils doivent correspondre aux valeurs de portal_type dans la déclaration des classes)
meta_type : pas important pour ce tuto, mettez ça et mangez du saucisson.

À présent on va les définir ; pour ce faire, dans le dossier default on crée le dossier types .
Dedans, on va créer 2 fichiers .xml qui auront pour noms ceux de nos objets fraichement enregistrés :
soient DossierHistoire.xml et Histoire.xml .

Voici DossierHistoire.xml :

Bon allez c'est la ligne droite : si vous ne vous plantez pas comme senna après ça c'est la fin de la partie.

ligne 2 : le nom de notre objet : le même que celui écrit dans types.xml .
ligne 3 : le même que celui écrit dans types.xml.
ligne 6 : le titre de notre objet : on met le nom de l'objet .
ligne 7/8 : une description pour notre objet.
ligne 10 : ici on met le nom de notre objet.
ligne 11 : le produit auquel appartient l'objet : notre egg.
ligne 12 :  on définit un factory qui doit être de la forme : addMonType.
Il sera créé par Archetypes (cf une future partie).
Il va être chargé entre autre (pas sûr de l'orthographe) de créer l'objet.
ligne 14 : absolument inutile pour le moment.
Est censé nous rediriger sur la vue (en l'occurence atct_edit, créée automatiquement par Archetypes) une fois l'objet créé, mais ne fonctionne pas pour le moment.
ligne 16 : à True, permet d'ajouter notre objet depuis n'importe quel autre objet.
ligne 17 :  Va avec les lignes 18, 19 et 20 . à True, permet de filtrer les objets que l'on peut ajouter dedans.
ligne 18 : Comme on a mis à True la propriété précédente, on doit indiquer les objets que l'on peut ajouter dans notre objet à l'intérieur de cette balise ;
ligne 19 :  ceci ce fait via <element value="MonType" /> : ici, on autorise seulement les histoires à être ajoutées dans notre DossierHistoire ( normal hein).
ligne 20 : on ferme la balise.
ligne 21 : Si on autorise les commentaires sur notre objet , bien sûr que non ! donc False. Manquerait plus que ça ...
ligne 22 : la vue par défaut de notre objet cad qu'accéder à  www.jesuisunconnard.com/monObjet/ revient à www.jesuisunconnard.com/monObjet/maVueParDefaut . Ici la vue par défaut est derniers que l'on verra dans une autre partie.
ligne 23/30 : heureusement que c'est la fin, je commence à manquer de couleurs.
Liste les différentes vues d'affichage disponibles pour notre objet (que l'on verra via "affichage"), la vue aleatoire sera créée également plus tard, les autres existent déjà.
ligne 32 : "surchage" la ligne 22. Accéder à www.jesuisunconnard.com/monObjet/ reviendra à www.jesuisunconnard.com/monObjet/maVueAffichageParDefautEnCours
ligne 33 :  action "editer" notre objet : nous redirigera sur la vue atct_edit.
ligne 34 :  action "partager" notre objet: nous redirigera sur la vue @@sharing.
ligne 35 :  action "voir" notre objet : nous redirigera sur la vue d'affichage actuelle de notre objet.
ligne 36/37/38 : Appuyer sur le bouton "voir" est associé à l'action "voir"(ligne 34 ) , le lien sera de la forme : www.jesuisunconnard.com/monObjet/ et sera accessible par tous.
igne 39 : on la ferme
ligne 40/41/42 : Appuyer sur le bouton "Edit" est associé à l'action "edit"(ligne 33 ), le lien sera de la forme www.jesuisunconnard.com/monObjet/edit et sera accessible uniquement par les admins.
ligne 43 : on la ferme
ligne 44 : fini !

Voilà,je suis conscient que les explications doivent être assez pourries pour ces 44 lignes mais j'aime le chocolat.

je ne ré-explique pas le fichier Histoire.xml que voici :

Puisqu'il y a exactement les mêmes balises.


Si vous remaquez une des erreurs, n'hésitez-pas,
pour les questions pareil ( d'ailleurs mon mail david [arrobase] qui-saura [point] fr ne marche toujours pas [je dois compiler postfix à "la main" pour avoir les modules sasl&co] donc désolé pour ceux à qui je ne peux plus répondre, utiliez le mail de la page "A propos" ).

Pour rappel, l'AFPY possède un flux RSS avec des nouvelles fraîches parlant de Python.

L'adresse du flux est ici : http://www.afpy.org/planet/rss.xml

Un Planet nommé Yap fabriqué avec Pylons présente ce flux sur le site de l'AFPY :

http://www.afpy.org/planet/

Le flux lui-même est créé grâce à Atomisator, le framework d'agrégation web de Tarek, à partir d'une liste de sources prédéfinie. Si vous possédez un blog parlant de Python, ou qui peut être filtré par Tag, Catégorie ou Recherche sur Python, vous pouvez m'envoyer l'adresse et je l'ajouterai à la liste.

Ces langages sont accessibles, il ne faut pas une semaine pour faire son premier programme mais une après-midi, il suffit juste d'être motivé pour essayer et pouvoir en juger par soi-même. Il y a énormément de support derrière (listes de diffusion, salons irc, tutoriels, blogs, etc) donc ce n'est finalement qu'un problème de « barrière psychologique » qui peut venir :

D'une peur de l'inconnu

Ou peut-être plus surestimation finalement. Il ne faut pas croire que certains langages sont réservés à certaines personnes ultra-compétentes, c'est faux.

Le plus marrant c'est qu'il s'agit du contraire avec ces langages car ils permettent de créer ses premières applications très rapidement, sans avoir besoin de connaître toutes les fonctions/modules de la bibliothèque standard.

Pour reprendre un témoignage récent :

je l'ai [Django] testé, et ai été assez épaté par sa simplicité et sa puissance. Je suis fan de Symfony, mais il est assez complexe, et sa courbe d'apprentissage est rude. Django m'est apparu bien plus simple. Sans connaître Python, j'ai pu en quelques heures seulement commencer à jouer avec le framework, réaliser une première application, la faire évoluer assez rapidement...

Il faut aller au-delà de cette peur, prendre le temps d'essayer et de juger si ça vaut l'investissement en temps que vous allez y consacrer. C'est un risque mais... une vie sans risque doit être bien ennuyeuse ! :-)

D'un manque de confiance en soi

Suivre un tutoriel d'apprentissage est rapide et facile. C'est lorsqu'il faut aller plus loin que ça prend du temps (j'apprends encore de nouvelles choses sur Django et Python quasi-quotidiennement), mais si un simple tutoriel vous permet d'apercevoir les fondements du langage et s'il va vous plaire ou pas. Ces tutoriels ne sont pas réservés à une élite !

Après il faut aussi accepter de repartir, non pas de rien (si vous connaissez Symfony par exemple, essayer/adopter Django sera très simple) mais forcément apprendre de nouvelles méthodes, de nouvelles façons d'envisager certains problèmes. Accepter de redevenir débutant fait du bien mais demande une bonne part de confiance en soi, en sa capacité d'adaptation.

D'un manque de curiosité

Il est bien sûr plus simple de rester dans son petit confort mais c'est peut-être ce qui me déprime le plus, penser qu'il y a des développeurs qui vont utiliser pendant 10 ans une même techno, sans essayer autre chose alors que l'on fait un métier qui permet de ne jamais s'ennuyer grâce à son évolution constante.

Je commence à bien connaître Python et je n'en deviens pas monomaniaque pour autant, je suis conscient de ses limites et j'explore d'autres pistes qui pourraient y pallier. Bien sûr ça demande un certain effort mais je considère que ça fait partie de ma veille technologique quotidienne.

Pour revenir à l'événement, mon but n'était pas de convaincre tout le monde de passer à Django mais juste d'attiser la curiosité de certains (ce qui aura au moins marché pour une personne \o/).

En guise de conclusion, j'ai écrit un article pour Linux Magazine qui devrait être dans vos kiosques et qui permet de débuter avec Django en prenant l'exemple de développement d'un blog (très proche de celui de Gilles). L'avantage c'est qu'il s'agit aussi d'une comparaison avec d'autres frameworks web Python vous permettant de choisir en fonction de vos besoins. Si votre curiosité vous démange ;-).

In your project's urls.py, add this urlpattern:

... YOUR URLS HERE ...

from django.conf import settings

if settings.DEBUG:
    urlpatterns += patterns('',
        (r'^media/(?P<path>.*)$',
            'django.views.static.serve', {
                'document_root': settings.MEDIA_ROOT,
                'show_indexes': True,
            },
        ),
    )

With this pattern, static files will be available at the URL: /media/. Don't forget to adjust settings.MEDIA_URL:

MEDIA_URL = '/media/'

And to avoid conflicts, we need to redefine settings.ADMIN_MEDIA_PREFIX:

ADMIN_MEDIA_PREFIX = '%sadmin/' % MEDIA_URL

When your project is ready for production use, you can define different settings.MEDIA_URL. For example, depending on settings.DEBUG:

if DEBUG:
    MEDIA_URL = '/media/'
else:
    MEDIA_URL = 'http://media.yourdomain.com/'

But you can define a DEVELOPMENT_MODE setting or anything else. Take a look at the djangoproject.com settings.py. It uses the platform.node() trick.

Into your templates, it is recommended to use {{ MEDIA_URL }} instead of /media/:

<link rel="stylesheet" type="text/css" media="all" href="{{ MEDIA_URL }}css/main.css" />

Now if you modify settings.MEDIA_URL, you will not have to modify all your templates. Thanks to django.core.context_processors.media which adds media-related context variables to the context. This context processor is enabled by default.

To know more about how Django serves static files: How to serve static files.

La dernière fois je vois ai parlé d'une des premières applications disponible en Django permettant d'intégrer un CMS dans son site, nommé Django-cms. Mais mon retour sur cette application m'avait laissé un petit goût de frustration, me laissant penser que ce n'étais pas encore au point. Mais cela va mieux avec Django-page-cms.

Ce dernier en plus des fonctionnalités essentielles, comme la gestion de l'arborescence dans le module d'administration et la prise en charge de différents langages, possède certains atouts qui en font mon favoris.

Voici les petits plus qui m'ont séduit :

• Définition de plusieures zones de contenus dans un template. (trop fort !)
• Surcharge des urls existante dans le CMS. (enfin !)
• Possibilité d'édition du contenu directement depuis le Front. (la classe !)
• Les contenus du CMS peuvent être interprétés en temps que code. (super !)
• Pas de besoin de définir une "RootPage" comme dans Django-cms.
• Gestion des révisions.
• Code propre.

De plus j'ai pu tester la rapidité de l'équipe du projet qui a intégré en moins de 12h ma contribution pour fixer un bug mineur.

Un projet qui mérite donc d'être suivis.

Le site de web de Django-pages-cms.

Edit du 7 avril 2009 : une traduction en français est désormais disponible, ou ici.

D'autre part, il est intéressant de noter qu'on redemande aux traducteurs de tous poils de se remettre à l'ouvrage, afin de fournir des traductions pour PyRoom dans toutes les langues de la terre du monde. Avis aux amateurs. Avec Rosetta, il suffit d'un simple navigateur web et c'est joué.

Je rappelle que les rapports de bug se feront via Launchpad, merci.

Tiens ! En parlant de launchpad, d'ailleurs, j'ai eu le plaisir de voir un texte que j'avais adressé à sa demande à Matthew Revell débarquer sur le blog de Launchpad. Il m'avait simplement demandé pourquoi j'avais opté pour la plateforme Launchpad pour héberger PyRoom. Je ne pensais pas que ça en ferait un article...

Et pour finir, cerise sur le gâteau, si on va fouiller dans les répertoires archives de vidéos du dernier Fosdem, on peut tomber sur la vidéo d'un type mal rasé, arborant un horrible accent outrageusement britannique et qui explique à un parterre assez dubitatif pourquoi PyRoom est un outil intéressant, bien que dépouillé au maximum.

Le son crache, c'est horrible, mais c'est pas ma faute, désolé.

C'est avec un plaisir non dissimulé que je vois enfin mes articles et ceux de David publiés dans Linux Mag n°114. Initialement ils devaient paraître dans le Hors-Série n°40, actuellement en kiosque, mais les 26 pages d'articles n'ont pas pu rentrer et ont été reportés dans ce numéro régulier :

C'est découpé en trois parties. La première, en 6 pages, fait le tour des techniques de publication web en Python depuis le vieux CGI, jusqu'au WSGI, avec un petit benchmark sur les différentes techniques. Ensuite, 7 pages de présentation de trois frameworks web en parallèle : Pylons, Django et Zope 3, accompagnée d'un rapide tutoriel. Enfin, un comparatif technique un peu plus long (13 pages) qui présente les différents aspects (M, V, C, sécurité, administration) des frameworks, toujours en parallèle.

Je tiens à signaler une belle erreur de PAO à la page 81 : « Pylons, une alternative proposée par Google ». Bien évidemment Pylons n'est pas du tout proposé par Google :) Il faut séparer le titre du chapitre « Pylons » de ce qui devait normalement être un encart à propos de Google App Engine, et qui s'est malencontreusement transformé en paragraphe.

Sinon, un nouveau merci à Philippe Biondi, Gael Pasgrimaud et Thierry Florac pour leur aide sur ces articles.

Voir un aperçu du magazine

Vous devez désactiver/activer un fichier css, mais vous en avez marre de devoir passer par le portal_css de la ZMI parce que vous ne savez pas le faire en python ?

Et bien voilà le petit bout de code :

 
Et c'est tout.

Élu billet le plus court de l'année.

ps : la partie 3 ne devrait pas tarder (me reste juste à tenter d'expliquer un .xml, mais vu qu'il est long....)

J'ai enregistré hier bgk.me pour remédier à ça et avoir mon propre service de redirections courtes. Ça prend une centaine de lignes en Python et c'est sous WTFPL, comme ce blog. Enfin HTML5 c'est juste pour être plus concis, rien de bien évolué dans ce domaine, allez voir l'excellent billet de Maurice si vous voulez apprendre à exploiter certaines capacités utiles de HTML5.

Choix techniques

Au niveau des fonctionnalités :

• la possibilité de rediriger facilement vers mes billets ou mes brèves ;
• la possibilité de choisir un nom de raccourci pertinent (je déteste les tinyurls qui ont un hash ne permettant pas d'avoir une idée de ce qu'il y a derrière) ;
• une interface d'administration simpliste.

Il y a des centaines de façons de coder ça et j'aurais aussi pu utiliser ur1 en PHP mentionné par znarf, je pense que c'est une bonne solution aussi, tout dépend de votre infrastructure. Edit : Xavier vient de mentionner urly en Python aussi.

Je voulais rester super simple, un seul fichier, pas de base de données et une base qui ne soit pas une usine à gaz comme Django, inutile dans notre cas. J'ai donc opté pour webpy qui est excellent pour ça, bon c'est devenu un peu trop complet à mon goût encore (ah le bon temps où ça tenait dans un fichier unique :-)) mais suffisamment simple à prendre en main pour ceux qui voudraient se mettre à Python ;-).

Redirections

On commence par les redirections des billets et brèves, il faut pour cela ajouter les URL suivantes :

urls = (
    "/p/(\d+)",         "RedirectToPost",
    "/t/(\d+)",         "RedirectToThought",
)

Et ensuite construire les classes de redirection :

class RedirectToPost:
    def GET(self, post_id):
        return web.redirect(POST_REDIRECT_URL % post_id)

class RedirectToThought:
    def GET(self, thought_id):
        return web.redirect(THOUGHT_REDIRECT_URL % thought_id)

Ici vous pouvez voir que j'ai misé sur la réutilisation du code en définissant pas mal de variables en début de fichier permettant d'adapter facilement le code à votre propre usage. Grâce à ces redirections, http://bgk.me/p/270 va rediriger vers ce billet par exemple.

Passons maintenant au redirections vers d'autres URL, ici aussi il faut ajouter une entrée dans les URL :

urls = (
    "/(.*)",            "RedirectToOthers",
)

Là il faut aller chercher les URL qui ont été créées via l'admin (que l'on verra ensuite) et qui sont stockées dans un objet shelve qui permet rapidement d'avoir une correspondance clé-valeur en Python.

class RedirectToOthers:
    def GET(self, short_name):
        storage = shelve.open(SHELVE_FILENAME)
        # shelve does not allow unicode keys
        short_name = str(short_name)
        if storage.has_key(short_name):
            response = web.redirect(storage[short_name])
        else:
            response = FAIL_MESSAGE
        storage.close()
        return response

Ici aussi ça reste très simple puisque ça redirige vers l'URL trouvée ou ça affiche un message d'erreur.

Administration

Bon si vous avez toujours un shell ouvert sur votre serveur, vous pouvez directement remplir votre fichier shelve avec le shell Python. Mais ça coûte pas grand chose de faire une admin toute simple pour pouvoir faire ça en web alors on ne va pas s'en priver.

Pour protéger cette URL, on va juste la rendre difficile à trouver, je vous laisser utiliser ce qui vous semble le plus pertinent, ici aussi dans une variable :

urls = (
    ADMIN,              "Admin",
    ADMIN+"/done/(.*)", "AdminDone",
)

La classe Admin vous permet d'afficher le formulaire et de soumettre une nouvelle correspondance raccourci-url :

class Admin:
    def GET(self):
        admin_form = web.form.Form(
            web.form.Textbox("url",     description="Long URL"),
            web.form.Textbox("shortcut",description="Shortcut"),
        )
        admin_template = web.template.Template("""$def with(form)
        <!DOCTYPE HTML>
        <html lang="en">
          <head>
            <meta charset=utf-8>
            <title>URL shortener administration</title>
          </head>
          <body onload="document.getElementById('url').focus()">
            <header><h1>Admin</h1></header>
            <form method="POST" action="/admin">
              $:form.render()
              <input type="submit" value="Shorten this long URL">
            </form>
          </body>
        </html>
        """)
        return admin_template(admin_form())

    def POST(self):
        data = web.input()
        shortcut = str(data.shortcut) or random_shortcut()
        storage = shelve.open(SHELVE_FILENAME)
        if storage.has_key(shortcut) or not data.url:
            response = web.badrequest()
        else:
            storage[shortcut] = data.url
            response = web.seeother(ADMIN+'/done/'+shortcut)
        storage.close()
        return response

Les formulaires et templates de webpy sont utilisés directement dans le code ici car ils restent super concis. Si c'est un GET on construit le formulaire et on l'envoie au template, si c'est un POST on ajoute l'URL à la base et on redirige vers la page de confirmation. Très peu de vérifications car ça ne sert pas à grand chose dans ce cas, on s'assure juste de ne pas écraser une URL existante et qu'une URL a bien été soumise.

Il ne reste plus qu'à afficher une page la page de confirmation avec le lien nouvellement créer (en dur sinon on pourrait facilement détecter votre admin grâce au referer...) et un raccourci pour tweeter le lien directement :

class AdminDone:
    def GET(self, short_name):
        admin_done_template = web.template.Template("""$def with(new_url)
        <!DOCTYPE HTML>
        <html lang="en">
          <head>
            <meta charset=utf-8>
            <title>URL shortener administration</title>
          </head>
          <body>
            <header><h1>Done!</h1></header>
            <p>You created: $new_url</p>
            <p><a href="http://twitter.com/home?status=$new_url" 
              title="Tweet it!">Tweet it?</a></p>
          </body>
        </html>
        """)
        return admin_done_template(SERVICE_URL+short_name)

Et voilà, après vous pouvez ajouter tout pleins de choses mais la base est là, suffisante pour mon usage. Ça m'a pris 2h et 10€ (car ils se gavent sur les .me mais c'est la seule extension qu'il restait) mais c'est le prix de l'indépendance.

Mise en production

J'utilise lighty, à adapter selon votre configuration (ne pas oublier de rendre code.py exécutable et de modifier ADMIN !) :

$HTTP["host"] =~ "bgk.me" {
        server.document-root = "/path/"

        fastcgi.server = (
            "/code.py" => (
                "main" => (
                    "socket" => "/path/bgkme.socket",
                    "bin-path" => "/path/code.py",
                    "max-procs" => 1,
                    "bin-environment" => (
                        "REAL_SCRIPT_NAME" => ""
                    ),
                    "check-local" => "disable"
                )
            )
        )

        url.rewrite-once = (
            "^(/.*)$" => "/code.py$1",
        )
}

Pour terminer, le code est sur ma ferme de dépôts, à utiliser, modifier, critiquer sans modération, enjoy!

Deux ans après Zope 3.3, voici enfin Zope 3.4, sorti le 29 janvier 2009. Zope 3 est une plateforme logicielle pour le web, c'est-à-dire un ensemble cohérent de briques de programmation pour créer des sites et des applications web. La particularité de Zope 3 est de permettre un découpage propre d'une application en composants réutilisables et interchangeables, chaque composant correspondant à une fonctionnalité bien délimitée, décrite et documentée par une ou plusieurs interfaces. Les composants peuvent être développés et testés séparément, puis changés ou étendus sans impacter le reste de l'application. C'est une garantie de fiabilité, perennité, et extensibilité pour de grosses applications.

$ easy_install zopeproject
$ zopeproject HelloWorld
$ cd HelloWorld
$ bin/helloworld-ctl foreground

$ svn co svn://svn.zope.org/repos/main/z3c.formdemo/tags/1.5.3 formdemo
$ cd formdemo
$ python bootstrap.py
$ ./bin/buildout -v
$ ./bin/demo fg

Si vous n'avez pas lu la 1°partie, je vous invite à le faire tout de suite : il y a quelques notions (  c'est quoi un profil, comment ca fonctionne, etc...) à connaitre.
Et son code se trouve toujours là.

À partir de cette partie on va s'occuper du paquet jesuisunconnard.metier .

C'est lui qui va nous permettre réellement de faire de notre site Plone le site jesuisunconnard.
En effet, on va y créer:
- nos Vues (nos nouvelles pages : À propos, Raconte ton histoire, etc...).
- nos contenus ( Histoire et DossierHistoire) via Archetypes.
- etc ...

Mais dans cette partie, on va "seulement" créer nos deux classes.

Bon bah, c'est parti mon kiki .

Création du paquet

Namespace du paquet : jesuisunconnard
Le nom du paquet : metier
Zope2Product : True

Donc maintenant il faut mettre à jour le buildout.cfg :

Bon, maintenant que le paquet est créé on peut passer aux choses sérieuses.

Interfaces

On va donc commencer par créer nos interfaces .
Elles vont servir à décrire comment nos classes les implémentant doivent se comporter.

fichier src/jesuisunconnard.metier/jesuisunconnard/metier/interfaces.py :

(bon ok le bleu et le orange ça ne va pas du tout ensemble...)
le _ va nous servir pour l'i18n, je ne vais pas en parler maintenant(on verra ça dans une des dernières parties je pense), mais il va permettre de marquer nos chaines en tant que chaines à traduire.

Ici, on déclare 2 classes: IHistoire et IDossierHistoire qui deviennent des interfaces en héritant d'Interface.

IHistoire a 2 attributs:
nom : l'auteur de l'histoire,
texte : l'histoire.
 
IDossierHistoire a 1 seul attribut:
titre  : le titre du dossier.
contains() indique que nos dossierHistoire ne devront contenir exclusivement que des objets implémentant IHistoire, cad uniquement des Histoire.

Quand on voudra écrire/éditer une Histoire :
le nom : devra etre une chaine représentée par un "<input type="text">",
le texte : devra etre une chaine représentée par un "<textarea>".

Quand on voudra ajouter un DossierHistoire:
le titre : devra etre une chaine représentée par un "<input type="text">".

Et c'est fini pour nos interfaces.

Contenu

Maintenant on va s'occuper des classes les implémentant : Histoire et DossierHistoire qui vont etre le "contenu" de notre site.

On crée un dossier content dans src/jesuisunconnard.metier/jesuisunconnard/metier, agrémenté d'un fichier __init__.py .

Pour créer nos classes, on va se servir du framework Archetypes, et ca va se passer en deux temps :
- on va d'abord créer le schéma
- puis notre classe.
et Archetypes se chargera du reste ( sauver/supprimer les objets, nous créer les pages d'affichage/édition/suppression, et j'en passe) ! Si c'est pas beau çà ?!

Le schéma : c'est là où on va définir les champs que l'on souhaite avoir pour notre classe .
La classe : on va seulement implémenter notre interface, mettre dans un attribut notre schéma, et ce sera fini (enfin il y aura 2-3 bricoles à faire, mais c'est tout).

Bon, c'est pas très parlant, donc on va passer à la pratique.

 On a notre classe Histoire ; lorsque l'on voudra en créer/éditer une, il nous faudra  logiquement:
- un champs  <input type="text"> pour l'auteur de l'histoire
- un champs <textarea> pour le texte de l'histoire 

OK  ? (en même temps vous avez pas le choix)
Et bien on aura juste à définir ces deux champs dans le schéma de notre Histoire.

Ce qui donnera pour le schéma:

On doit commence par copier le schéma ATContentTypeSchema.
Il va nous copier le schéma de base(création d'un champs id, title, description, etc...).
Ensuite on rajoute nos 2 champs :
- nom : un simple StringField, vu que l'on souhaite quelquechose du type <input type="text">
- histoire : un TextField, vu que l'on souhaite quelquechose du type <textarea>

Les deux sont obligatoires ( nb : à remplir ) et seront indexés.
storage : à ne pas oublier, il faut mettre AnnotationStorage() (afin d' éviter des problèmes de namespace).
defalut_output_type :  'text/x-html-safe', afin d'échapper les caractères spéciaux, pour éviter le XSS ( et oui ya des cons de partout)
widget : Ce sera le widget que l'on verra sur la page d'ajout par exemple, pour représenter le champs :
- pour le nom : ,ce sera StringWidget, c'est à dire un <input type="text">
- pour l'histoire : ce sera RichWidget, c'est à dire un WYSIWYG ( un textarea amélioré).

Là  quelquechose vous titille l"occiput :
"mais il sert à rien le paramètre widget puisqu'en fonction du champs on sait de suite le widget qui va le représenter !"
Et bien pas tout à fait, puisque un champs peut avoir plusieurs widgets de disponibles, par exemple TextField peut avoir comme widget RichWidget  ou bien TextAreaWidget (un simple textarea).

Enfin,on appelle la fonction finalizeATCTSchema().
Elle va juste servir à finaliser la création de notre nouveau schéma, ya pas réellement besoin d'en savoir plus (elle va réordonner les champs, et en renommer certains).

Et voilà, l'explication du schéma est finie.

Place à la classe :

Histoire doit hériter de ATCTContent  puisque c'est un contenu (ça va lui permettre d'accéder à des méthodes&co de contenus).

Ensuite, on implémente IHistoire, normal.

Puis on déclare le type plone de notre classe via portal_type(les différents types plone sont accessibles à partir de portal_types).
( À noter que l'on déclare juste un type, il faut aussi le définir. Cela se fera via un fichier xml dans le futur profil de notre paquet métier )
_at_rename_after_creation : afin de renommer automatiquement notre objet si son id est foireux( doublon, caractère(s) interdit(s), etc...)

Notre schemaHistoire vient se greffer à notre classe via l'attribut schema.

Et puis on déclare nos 2 attributs nom et texte puisqu'ils sont présents dans l'interface. 
via ATFieldProperty(), nom et texte vont prendre respectivement les valeurs des champs nom et histoire et inversement proportionnel, les champs nom et histoire vont contenir les valeurs des attributs nom et texte.

Et là vous pouvez vous dire (en tout cas moi, ça m'avait choqué):
"mais pourquoi doit-on "re-déclarer" nos 2 attributs alors qu'on les a mis dans le schéma ? nom d'une pipe!"
Bah parce que :
- le schéma peut comporter moult champs que l'on ne souhaite pas forcément sauvegarder dans notre objet (par exemple, on se fout royalement du champs description, présent par défaut dans le schéma).
- on implémente une interface, donc il faut implémenter "explicitement" ses attributs&co (meme si python n'en a rien à foutre qu'un attribut manque à l'appel).
- pour accéder plus facilement aux valeurs
- etc...

 Et on termine par l'incontournable registerType() !
Qui va enregistrer notre classe Histoire, et lui  ajouter 3 méthodes pour chaque champs:
- un accesseur == getter (pour accéder à la valeur)
- un accesseur d'édition == édition ( pour éditer la valeur)
- un mutateur == setter (pour mettre une valeur)

 PROJECTNAME va contenir le nom de notre paquet, que l'on définira ultérieurement dans un futur fichier config.py

 Et voilà on a notre classe toute belle, pas chère, et prete à travailler!

La vérité

Nous on va  etre intelligent pour une fois.
Je vous ai dit, que les schémas de nos classes contiennentt des champs par défaut dont title et description.
Alors pourquoi re-créer des champs, on a qu'à s'en servir, non ?

Pour accéder à un champs d'un schéma c'est comme ca :

Pour notre classe DossierHistoire, on a besoin que d'un seul attribut donc d'un seul champs  et il faut que ce soit un simple <input type="text"> donc on va se servir du champs title .
Voici jesuisunconnard.metier/jesuisunconnard/metier/content/DossierHistoire.py :

On copie ATFolderSchema et non pas ATContentTypeSchema puisque c'est, certes un contenu, mais aussi un dossier . 
Tout comme la classe DossierHistoire hérite de ATFolder et non pas de ATCTContent puisque c'est un dossier.

Pour notre classe Histoire on va servir du champs title et description ( qui va nous fournir, quant à lui, un WYSIWYG).
Voici jesuisunconnard.metier/jesuisunconnard/metier/content/Histoire.py :

Et voilà, c'est terminé !

Alors dans la 1° partie, j'avais écrit qu'en une semaine, le tuto serait terminé,
et bien je me suis trompé ! 
En une semaine, je viens à peine de terminer cette partie,
et donc, je m'en excuse (enfin aux rares qui suivent mes articles)

Mais si j'ai mis si longtemps, c'est pour diverses raisons :
- coupures de courant
- coupures du net ( vidéotron....)
- je met véritablement beaucoup de temps pour écrire un article, meme trop
- et un grave manque de motivation, j'ai pas vraiment aimé l'écrire sauf une fois fini( faut dire que j'ai passé réellement 3 jours à savoir comment présenter Archetypes)

Alors il me semble que cette partie soit moins bien faite que la première, tantpis, enfin si vous avez des critiques n'hésitez pas

Ce sera une partie par semaine dorénavant.

Donc Rendez-vous à d'ici dimanche pour la 3° partie (configure.zcml de content et fichier config.py en perspective et que sais-je), enfin si l'envie m'endive...

Devant les indisponibilités de chacun, je me suis donc proposé. Cela faisait quelques années que ça me démangeait d'aller au FOSDEM, poussé par les membres de la communauté LugRadio, qui étaient habitués de l'événement.

En fait, quelques jours avant FOSDEM, j'ai regardé le programme et j'ai de suite senti la différence avec le Lugradio Live. Beaucoup, beaucoup, beaucoup plus de scènes, certes, mais beaucoup moins de sujets qui pouvaient m'intéresser aussi. Une piste entière dédiée à Drupal, très peu pour moi, merci, une autre sur Ada (os court, le langage vert !). Peu de choses liées au web (il y avait Ruby & Rails et Mozilla pour sauver l'honneur des développeurs web). Quant à Python, que dalle. Ou presque. Si on excepte la présentation de Victor Stinner sur Fusil et celle que j'ai donnée sur PyRoom, y'avait rien à se mettre sous la dent.

Encore une fois, cela n'a rien à voir avec l'organisation. FOSDEM est une énorme machine, il en faut certainement pour tous les goûts, et comme Olivier Grisel et moi en avons convenu en en parlant : il suffisait que les Pythonistas européens se mettent d'accord pour proposer des choses pour FOSDEM et les organisateurs auraient sûrement apprécié. Apparemment, lors d'une année précédente, il y avait un atelier Python qui paraît-il était plein à craquer. Ça doit être que je suis arrivée la mauvaise année. Peut-être que pour le prochain PYCON, il faudra glisser l'idée de proposer des animations en coordination avec les autres groupes de Pythonistes Européens, je suis certain que ce langage mérite plus de visibilité à l'échelon international.

Autrement, pour l'ambiance de l'événement, rien à dire : des bénévoles à fond les manettes, des geeks partout, l'indispensable Josette toujours fidèle au stand O'Reilly, un panneau "GNOME love / GNOME hate" très marrant, etc.

Ce fut l'occasion pour moi de discuter avec des gens que je n'avais jamais rencontré (salut Ploum) et revoir d'autres que je ne vois pas assez souvent et de boire de très bonnes bières belges avec plaisir.

J'ai même eu l'occasion de voir Tristan Nitot en chair et en chair. Ouaou.

En ce qui concerne ma conférence, je n'ai qu'un regret : celui d'avoir voulu modifier au tout dernier moment la taille du seul screenshot qui devait être affiché, et qui a trop largement débordé de l'écran. Autrement tout est allé comme sur des roulettes, et j'ai même gagné un paquet de mignonettes (c'est des biscuits) à la fin (comme tous les gens qui ont fait un Lightening talk - je trouve l'idée excellente). La présentation a été apparemment très bien reçue et j'espère qu'elle attirera plus d'utilisateurs et plus de contributeurs sur PyRoom.

D'ailleurs le présent article a été rédigé à l'aide de PyRoom. Voilà. Eat your own dog food.

Alors , dans ce tuto on va voir comment  créer une appli Plone 3.

Je ne sais pas combien il y aura de parties, mais je vais essayer de publier et terminer cette intro le plus vite possible ( en une semaine ce serait pas mal).
Et donc du coup l'intro à Zope 3 est mise en berne .

Le site que l'on va faire ? jesuisunconnard.com (bah oui  à défaut d'etre connu, faut bien qu'il serve à quelquechose) .

Jesuisunconnard sera décomposé en 2 packages :
jesuisunconnard.politique
jesuisunconnard.metier ( j'ai pas trouvé mieux comme nom)

Alors oui, on ne va pas voir comment créer un thème vite-fait bien fait, mais je ferais surement un petit article après ce tuto d'intro.

Je ne vais pas non plus traiter les tests, très importants, mais ca prendrait bien trop de place dans cette intro à Plone 3, mais qui sait, surement dans un prochain (mais très lointain) article ?

Et avant de commencer :  je n'arrive pas à faire d'accents circonflexes sur opéra 10.

C'est parti.

Installation de Plone via Buildout

Répondez aux questions (mettez et laissez à on le debug_mode et verbose_security pour le moment ).

Et on lance le buildout :

C'est terminé.

 Le thème

Comme dit plus haut, on ne va pas faire de thème personnalisé : j'en ai trouvé un très joli, et comme je suis une quiche en design ca tombe bien !
C'est keepitsimple. Et il est disponible chez pypi.
On rajoute donc dans buildout.cfg, dans la section [eggs] ceci :

puis dans zcml de [instance] ceci :

Qui va créer un fichier dans parts/instance/etc/site-package-includes afin que Zope trouve notre joli thème.

Création de notre politique

Les 2 premières parties étaient assez triviales mais bon.

On  va donc créer notre package plone 3 :

Namespace du paquet : jesuisunconnard
Le nom du paquet : politique
Zope2Product : True

 Et comme vous vous en doutez, il faut rajouter ceci dans notre buildout.cfg :

Ce package va nous permettre de configurer globalement notre site Plone, c'est à dire que, grace à lui, on va pouvoir :
- rajouter un onglet
- lister uniquement nos types dans "ajout d'élément"
- modifier le nom du site
- ajouter par dépendances, d'autres packages
 [...]

Maintenant que notre politique est créée, on va éditer le fichier src/jesuisunconnard.politique/jesuisunconnard/politique/configure.zcml :

La balise five sert à enregistrer notre paquet en tant que Produit Zope2 .

la balise genericsetup, quant à elle, permet d'enregistrer un profil pour notre politique.

Mais c'est quoi un profil ? on va prendre une photo ?
Non ;  un profil va contenir certaines configurations pour notre site ( le nom, la description, les worflows, les roles, etc...)

Le profil s'appellera donc default.
Et directory est l'emplacement de ce profil.

Comme vous vous en doutez il faut donc créer les dossiers profiles et default :

Donc, comme dit juste avant, notre profil va contenir certaines configurations, qui se feront uniquement via fichiers XML.

 Configuration de notre profil

On va commencer par modifier le nom du site ainsi que sa description .
On crée donc le fichier src/jesuisunconnard.politique/jesuisunconnard/politique/profiles/default/properties.xml :

Et c'est tout.
la proriété title représente le titre du site et description la description [ je précise au cas où il y ait des ames égarées ].

Maintenant, on veut rajouter 3 onglets : "A propos", "Raconte ton histoire"  et "Aleatoire".
Ces 3 onglets vont, non pas rediriger vers un dossier (sinon on aurait pas besoin de les rajouter à la "main"), mais rediriger sur des pages que l'on créera dans une prochaine partie : 
on va donc préparer le terrain.

On va devoir créer le fichier src/jesuisunconnard.politique/jesuisunconnard/politique/profiles/default/actions.xml  et y mettre :

La 2° ligne permet de sélectionner notre objet, en l'occurence portal_actions ( d'où le nom du fichier).
Et oui, nos onglets vont être enregistrés dans portal_actions et plus particulièrement dans son objet portal_tabs ( tabs = onglets , je précise on ne sait jamais) : d'où la 4° ligne.

Et après c'est assez trivial poursuit :
à l'intérieur de portal_tabs, on définit 3 objets ( aPropos, ajout, aleatoire) étant de type CMF Action : et hop ce sont devenus des onglets.

title : le titre de l'onglet
description: la description de l'onglet
url_expr: l'url où pointe l'onglet : vide pour le moment
icon_expr: l'icone de l'onglet : on n'en veut pas
available_expr: condition éventuelle pour qu'apparaisse l'onglet
permissions: la permission pour l'onglet, ici, tout le monde peut le voir
visible: si l'onglet est caché (False) ou pas (True)

C'est bientot la fin

Il nous reste une dernière chose à faire, avant de terminer cette première partie.

Comme dit plus haut, je veux uniquement lister dans "ajout d'un élément" les objets que l'on créera dans une prochaine partie , c'est  à dire que "Document", "Evenement" et compagnie doivent disparaitre.
Et Comment on fait ça ?

On crée le fichier src/jesuisunconnard.politique/jesuisunconnard/politique/profiles/default/import_steps.xml, contenant ceci :

Mais c'est quoi ce fichier import_steps.xml ? tu veux qu'on fasse du step ?
Queneni !
Enfait quand on va installer notre paquet, genericsetup va importer notre profil default afin de configurer notre site .
Et cette configuration se fait étape par étape : normal.
Mais si l'on veut rajouter une étape comme c'est le cas ( lister seulement nos objets dans "ajout d'un élément"), on doit créer ce fichier.

on crée une nouvelle étape via la balise <import-step>, en oubliant pas de lui mettre un id.
Le handler sera ce que notre nouvelle étape va appeler ; ici, c'est la fonction importVarious() qui le sera.

Bon bah il ne nous reste plus qu'à la créer .
fichier src/jesuisunconnard.politique/jesuisunconnard/politique/setuphandlers.py :

importVarious ne fait qu'appeler desactiveTout().

On récupère l'objet portal_types (qui est un singleton) via getToolByName().
Puis, on récupère chaque objet représentant un type indésirable via getattr(portal_types, monType) ,  que l'on désactive via l' attribut global_allow.

Et voilà.

Et merde, c'est pas la fin

Ceci est le dernier paragraphe , mais le vrai.

Dans le paragraphe précédent, j'ai écris :
Enfait quand on va installer notre paquet, genericsetup va importer notre profil default afin de configurer notre site .
Vous avez du vous dire : "mais comment il sait qu'il doit importer default et pas un autre ou rien du tout ?

Et bien ca se passe du côté de chez swan du dossier src/jesuisunconnard.politique/jesuisunconnard/politique/Extensions, qu'il faut créer ( il faut en faire un package donc n'omellettez pas le fichier __init__.py ) .

Dedans, créez le fichier Install.py (avec le I majuscule) :

Ce code n'est pas de moi, je l'ai trouvé dans pas mal de codes et sur des sites, donc je n'ai pas vraiment de sources à donner.
Je ne vais pas l'expliquer, puisqu'on s'en fou du fonctionnement.

Tout ce qui nous intéresse c'est de savoir, que install() va permettre d'installer d'autres paquets :
il nous suffira d'ajouter le nom du paquet dans PRODUCT_DEPENDENCIES (on rajoutera par la suite jesuisunconnard.metier)

Et il nous permet aussi d'importer nos profils via EXTENSION_PROFILES  (monPaquet:nomProfil) .
C'est comme ca que genericsetup sait qu'il doit importer notre profil default.

Et c'est vraiment la fin de cette première partie ( n'oubliez pas de faire un buildout), si vous voulez le code c'est ici.

(et dire que je dois finir cette intro en une semaine...)

Relief.fr is an agency specialized in 3D stereographic technologies (what we call "relief" in french), located in Paris. It's a great team, they have a long-standing know-how with stereography, anaglyphs, 3D projection, and they also really master the production of images dedicated to the innovative 3D LCD panels from Alioscopy.

Stereoscopy normally needs making 2 images: one for the left eye, one for the right eye. Producing images for these 3D screen is much harder because they require shooting 8 images. Seeing such a screen for the first time is really astonishing, because you not only see in 3D without 3D glasses, but you can also turn around the object on the screen! Not a lot, but you can. Just put a screen on your stand in an exhibition, and you are guaranteed to see everybody stopping in front of you. I'll try to bring one at Solution Linux 2009 for the AFPY stand.

To be able to shoot 8 images, we need to move a camera on an aluminium rail very quickly, while the camera is in burst mode. Everything is home made. The rail and the power supply is manufactured by a motion control specialist, while I'm programming the movements of the stepper motor in Python, with an USB controller, an eee-pc, and everything on Linux.

Since I'm also a musician, I really like to do music with everything: that's really easy with a stepper motor: you just give him a frequency to make it move, and a frequency is just a note. Starting with the 440Hz A, you just have to multiply by the twelfth root of two ( 2^(1/12) ) to get the next semitone. Then you can play music :)

This is very noisy because the rail is on a wood box. The high notes are not exactly right, because of some harmonics, and also the rounding of frequencies to the nearest integer.