• Ce blog — désormais archivé — est en lecture seule.

Symfony live 2011 – Journée 1

Symfony CMF

Les conférenciers commencent par bâcher Drupal, en gros ce n’est pas bon sauf pour les utilisateurs finaux.

Ensuite on passe au CMF : Content Management Framework. Qu’est-ce dont ?

  • Une boite à outils pour créer son propre CMS.
  • Pas un truc qui rassemble tout mais un truc qui s’améliore avec le temps.
  • Diem, Apostrophe, Sympal construis sur la même base.

Et le projet Symfony CMF ?

  • Environ 100 personnes dans la mailing-list.
  • +10 par mois.
  • La plupart des décisions clés sont prises sur un forum public.
  • Soutenu par des entreprises tels : KnpLas, Theodo, ideato, Liip, OpenThink Labs, …

Au niveau technique, les données d’un CMS ne sont pas très gérables donc utilisation du NoSQL, pas de SGBDR. Certains CMs organisent des données en arbre, on peut utiliser : Graph DBs.

Pour Symfony CMF, on devrait avoir :

  • Versionning du contenu
  • Gestion fine des accès
  • Doctrine PHPCR ODM
  • Jackalope (Java)
  • Utilisation de PHPCR, une interface qui permet aux devs PHP de garder leurs habitudes (exemple : tableaux associatifs qui n’existe pas en Java). Ainsi, on ne discute pas avec Jackalope.
  • PHPCR/JCR ne sera pas utilisé pour tout sauvegarder. Les données « web », les commandes d’un site e-commerce (par exemple) ou ses stocks iront dans un SGBDR. Idem pour l’agrégation, mieux supportée et faite dans un SGBDR.

Adresse du projet : Symfony CMF.

Restful avec symfony et Symfony2

Définition/Explications d’un Web Service :

  • Développement d’APIs/Webservices
  • Communication inter-langages/inter-logiciels
  • Fournisseur : service
  • Agent : client
  • Deux types : REST ou WS-*

Web services en Symfony 1

  • Utilisation du système de routing
  • Utilisation d’un serializer qui n’est pas présent dans symfony ou Zend.
  • Il existe cependant un Exporter Doctrine.
  • En json : json_encode($object->toArray()) ;

Cependant, comment valider les entrées ? La présence du payload ? Hé bien en utilisant les validateurs de symfony.

Abordons la partie sécurité (accès, rythme, fréquence (throtting)) :

  • Autentification naïve par preExecute, ajouter un paramètre (une clé d’API par exemple) mais ce n’est pas terrible si quelqu’un trouve cette clé.
  • Approche OAuth plus que conseillée.
  • Throtting : utiliser Apache : mod_cband

Symfony2, on fait comment ?

Export des routes sf2 dans Apache2 :

    php app/console router:dump-apache

Il est conseillé de se servir du FrameworkExtraBundle pour le paramConverter !

En Symfony2, on a le Serializer component :

  • normalizer ; CustomNormalizer
  • GetSetMethodNormalizer : renvoit un tableau clé/valeur PHP
  • Encoder : JsonEncoder, XmlEncoder
    $serializer->addNormalizer(new CustomNormalizer()) ;

Varnish, HttpCache déclenchés avant l’initialisation du framework. Validation du cache :

    $response->setETag() ;
    if($response->isNotModified())
    {
         return ; //304
    }
    else
    {
        $response->setContent(contenu) ; 
        return $response ;
    }

Il est conseillé d’utiliser le Cache HTTP pour les Web Services pour éviter, par exemple, de parser les annotations Doctrine à chaque requête ! Enfin le supra projet, fil conducteur lors de la présentation : Symfpony :-D

Contributing with Git

A mon sens, la meilleure conférence des deux jours, présentée par @chacon. Déjà, voici quelques liens :

1991-2002 : pas de VCS pour le projet Linux.

Git vs SVN (rapide)

SVN : un log par fichier au premier commit, ensuite un log supplémentaire par modification.

Git : checksum de chaque fichier. Au comimit, enregistre un « manifest » avec les checksums des fichiers ajoutés. Au commit suivant, il recrée un checksum. Au renommage, il change juste le nom du fichier à côté du checksum dans le manifest. A la copie d’un fichier, il rajoute juste le fichier dans le manifest mais. => Liste chaînée de « snapshots » (checksums).

git diff fait un diff avec les snapshots concernés, pas avec tout.

Faire de beaux/bons commits :

  • Attention aux espaces (blancs)
  • git diff –check : pour vérifier avant de commiter
  • git add –patch : commit sélectif
  • git-gui
  • Git Tower
  • git-log –grep=xxx
  • short summary of changes

Branches

  • créer une branche pour toute nouvelle modification (majeure). Ne pas travailler sur Master.

Repository central

  • Premier arrivé, Premier Servi
  • git push
  • git fetch (d’abord)
  • puis : git merge

Merge

  • can undo the merge
  • more data for analysis later
  • easy continuous re-integration

Rebase

  • « prettier »
  • git pull –rebase : sinon pull fetch et merge
  • git merge –no-ff : no fast forward, gives more information

Processus de travail en groupe

  • Coder
  • git fetch
  • git log origin/master ^master
  • git rebase origin/master

Mailing List Contributor Workflow

  • git checkout my-branch
  • git format-patch –m origin/aster ⇒ xxxx.patch (email format patch)
  • git send-mail *.patch : configure your mail in ~/.gitconfig

Lorsqu’on reçoit le mail : ** git am xxx.patch

Repo personnel

Requesting a Pull : make your branch up to date ⇒ push to a named branch ⇒ contact the author

  • git remote add upstream http://xxx:yyy.git
  • git rebase upstream/master
  • git push origin my_feature
  • git checkout –b my_feature
  • commit, commit, …
  • git fetch upstream
  • git rebase upstream/master
  • git request-pull upstream/master origin

Accepting a Pull Request : git remote add scott http://xxx.yyy.git ⇒ git fetch scott ⇒ git merge scott/my_feature

Ou : git pull http://xxx:yyy.git my_feature

Symfony2 : 30 astuces et bonnes pratiques

  • Organisation plus libre
  • Application : une seule ⇒ système de sécurité permet de cloisonner efficacement
  • Pour utiliser plusieurs applications, on peut les nommer App1, App2, … Mais normalement on a besoin que d’une seule app’
  • Bundles ⇒ implémentation une fonctionnalité spécifique
  • Isoler ses classes métiers : Entity/ ou Business/
  • Utiliser ses propres namespaces…
  • Virer les bundles inutiles.
  • On peut définir des variables d’environnement : SYMFONY__XXX ⇒ Depuis un VHOST Apache2
  • Format .ini : pour paramètrage de l’application par un non-technicien.
  • Twig : XSS protection en automatique et mode sandbox
  • Utiliser le router Apache
  • Assets : Assetic

 Surcharge des pages d’erreurs

  • Créer un service (écouter core.exception, déclarer le service et créer une nouvelle classe).
  • Faire un template : on crée un app/FrameworkBundle/xxx.error.html.twig
  • Utiliser un contrôleur qui implémente la méthode showAction():
    framework :
        exception_controller : MyNS\MyBundle\MyExceptionController

Attention : les contrôleurs ne doivent pas hériter de la classe Controller du FrameworkBundle. Il ne faut pas créé de dépendances ! (c’est presque inutile). Donc les contrôleurs sont de simples classes PHP, sans dépendances. Il vaut mieux hériter du ContainerAware ou alors utiliser des services en tant que contrôleurs.

Twig

Assets ⇒ utiliser les blocks Twig Existence de macros pour Twig.

Injection de dépendances

  • classes utilisables sans Container
  • utiliser le format XML
  • A utiliser pour des objets qui ont une portée globale ou pour des objets « uniques ».
  • Ne pas utiliser l’injecteur pour des objets métiers.
  • Ne pas injecter le container dans les objets (lol) : injecter le service nécessaire !

Sécurité

  • déporter la configuration
  • spliter la configuration et l’importer

Profiler

  • utilisable en production
    framework :
        profiler :  { only_exceptions : true }
  • Génère un fichier.
  • Importer le dump dans le profiler.
  • Utiliser les annotations

FrameworkExtraBundle

  • configuration du routing
  • configuration des méthodes http
  • template à utiliser
  • cache http
  • convertir des paramètres de requête

 Performances

  • autoloading : compile les classes, attention à ne pas trop charger de classes
  • cache warmer : préparation du cache
  • pré-compilation du template, DI, routing, autoloading
  • On peut ajouter nos propres services.

Vérifier la configuration Doctrine

    php doctrine :ensure-production –settings

RabbitMQ

Why Messaging ?

The user

Upload picture, don’t want to wait till the images resizes. Notify user friends when she uploads a new image.

The sysadmin

Save my bandwith.

 The developer

Call the PHP from Python.

RabbitMQ & AMQP

Advanced Message Queuing Protocol * Interoperability * Open protocol * Binary protocol * AMQP Model : exchanges, message queues, bindings, rules for binding them * AMQP Wire Format : Functional layer, Message flow

 Scénario : batch

Requirements :

  • Generate XML
  • Distribution over a cluster
  • Elasticity
  • No code changes

Design : Enquue job -> generate xml -> direct exchnange -> desc queue -> Worker 1/Worker 2/Worker 3

    AMQPConnection()
    AMQPMessage()

Integration dans Symfony

RabbitMQ Bundle

Symfony2 Forms

Bon là, je n’ai pas pris de notes, ce fût une lecture de la documentation plus ou moins. J’ai tout de même noté deux infos :

  • L’astuce Twig pour rendre le reste des éléments d’un formulaire:
    {{ form.rest }}
  • Et le type : « repeated » to repeat twice a field (password)

Voilà pour cette première journée, plutôt longue mais très intéressante.

  • Print
  • Digg
  • StumbleUpon
  • del.icio.us
  • Facebook
  • Twitter
  • Google Bookmarks
  • FriendFeed
  • LinkedIn
  • MySpace
  • Netvibes
  • PDF
  • Ping.fm
  • RSS
  • Technorati
  • viadeo FR
  • Wikio
  • Yahoo! Buzz

Related Posts

Cet article a été publié dans SfLive, symfony avec les mots-clefs : , , . Bookmarker le permalien. Les commentaires et les trackbacks sont fermés.