Reprise du message précédent :
Bon les gars, faut qu'on parle sérieusement :
 
Vous utilisez quoi comme outil de SVN avec symfony et qui soit STABLE ?
 
Notre infrastructure :
- un serveur SVN sous ubuntu
- les checkout se font sur un disque partagé en samba sous un autre ubuntu
- on utilise Tortoise sous Windows en client
 
Bilan : régulièrement (1 fois par semaine sur les 4 dev), les check-out sont bloqués avec des messages d'erreurs abscons, voire le dépot est corrompu et on peut plus commiter quoi que soit.
 
Ca intervient souvent quand on regenère des modules ou ce genre de truc. Je milite pour utilisation du CLI sous linux mais je suis le 1er à admettre que c'est lourdingue.

Sous mac je reste en CLI... Relou pour les svn add et les analyses de logs mais c'est supportable je trouve.

Salut,
 
Aujourd'hui, je viens vous emmerder avec un problème de routing    
 
En fait c'est en codant intensivement des tests functionnels (note : à propos c'est ultime) que j'en suis arrivé à me poser quelques questions fondamentales sur le routing. Il faut dire que je n'ai jamais abordé sérieusement cette partie de symfony et que j'ai toujours fait des modifs mineures sans m'interoger sur le fonctionnement interne. En fait tout a commencé par  
 

 
Et là je me dis : "Mais que diantre, si j'ai un prefix d'url différent pour ce module, ça plante !"
 
Un exemple que j'ai (en propel) :
model : MpDateSejour
nom de table: mp_date_sejour
nom de la route : mp_date_sejour  (accessible avec le @ dans url_for, si j'ai bien compris)
nom du module : dateSejour (le nom du répertoire sur le disque)
nom du préfixe url de la route : date-sejour
 
Et non ça plantait pas. Parce que routing.yml finit par

 
Non ? (enfin j'ai la confirmation en CLI mais je préfère être 100% sûr)
 
De là ma question :  
 
Peut-on, ou même, faut-il jarter ce comportement par défaut du routing, pour des raisons de sécurité par exemple ou pour deceler plus facilement des bugs aussi ?  
 
Ou bien est-ce que beaucoup de composants symfony comme sfTestFunctionalBase citée plus haut assume ce comportement par défaut ?
 

Dans ma boite on a la même infrastructure, et on est nous aussi avec tortoise et on n'a jamais aucun souci

Je ne sais pas sur quelle version tu travailles, ni même si tu as encore le problème car il y a eu pas mal de temps depuis ton post, mais voici quelques informations.
En Symfony 1.4, quand tu installes un projet, le fichier de routing contient par défaut :

# generic rules
# please, remove them by adding more specific rules
default_index:
  url:   /:module
  param: { action: index }

default:
  url:   /:module/:action/*

Donc pour répondre à ta question, je te conseille très fortement de supprimer ces règles par défaut et de ne te servir que de tes propres règles, comme c'est indiqué à la ligne n° 2
Ensuite, depuis symfony 1.2 il me semble, tu ne devrais plus utiliser la syntaxe avec le '@' pour le routing.
Les helpers url_for et associé sont capable de le comprendre, mais seulement pour assûrer une certaine rétro-compatibilité. Le mieux si tu es sur une version supérieure ou égale à 1.2, c'est de ne plus utiliser le '@'.
 
Pour terminer, aucun composant de symfony n'assume comme tu dis ce "comportement par défaut".
 
La seule chose à savoir c'est que lorsqu'une requête entre, le système de routing cherche à matcher l'url demandée par rapport aux règles que tu as définis.
Si tu as défini une route /toto paramétrée pour atteindre l'action index du module test, alors si tu laisses les routes par défaut, tu peux accéder à la même action via /test/index et /test.

 
Ok faut que je change de lunettes
 
En effet ma question était toujours ouverte. (Le projet est en symfony 1.2).
Ok donc pour la suppression des règles par défaut.  
 
En fait ces 2 dernieres semaines j'ai du coder un webservice en symfony 1.4 (pour un autre projet) et je ne devais pas laisser les règles par défaut (par exemple tous les appels étaient en POST), je les ai justement supprimées. J'ai même sous-classé ma propre route pour checker certaines règles répétitives sur les paramètres. C'est vraiment puissant. Je me rends compte que y a toute une mécanique qu'on peut déporter de l'action vers la route. Ca et les sfFilter pour la sécurité, y avait quasiment plus rien dans mes actions executeXXXX    
 

 
Ok ça je savais pas. C'est noté    
 
C'est toujours bon de pêcher des recommandations à la source, merci

Salut
 
Je me suis mis il y a pas longtemps à découvrir comment fonctionnait Symfony 2, et après avoir lu la doc, il y a quelque chose qui m'échappe...
 
En fait je trouve ça très sympa comme modèle MVC
Cependant, dans tous les exemples présentés, à chaque fois la class des Bundle est presque tout le temps vide...
 
Or ce que je pensais au départ, c'est que le bundle était destiné à stocker toutes les fonctionnalités de ce bundle (Exploiter les différents repository, etc...), mais dans les faits, toute l'intelligence de l'application est faite directement le contrôleur...
 
Voici donc ma question : Le Bundle doit-il nécessairement rester vide (et donc il faut passer par des déclarations de services indépendants), ou peut-on justement l'utiliser pour centraliser les fonctions et dans ce cas je ne vois pas le bout de code à utiliser depuis un contrôleur pour récupérer l'instance d'un Bundle...
 
Par avance merci de vos lumières

En gros, attention à ne pas confondre le principe du Bundle et la classe de ton Bundle. Ton Bundle dans le sens global contient une ou plusieurs fonctionnalités en effet. Par contre, ce n'est pas la classe Bundle présente à la racine de ton bundle qui doit contenir ces fonctionnalités.

Elle, elle est présente pour faire interagir ton bundle avec l'injecteur de dépendances. Elle n'est donc pas nécessairement vide, mais elle ne contient pas d'intelligence. Elle sert juste à pouvoir donner à l'injecteur de dépendance des instructions par rapport aux services de ton bundle.

L'intelligence de ton appli elle, est contenue dans les contrôleurs, le modèle, les services, et n'importes quels objets contenus dans un sous répertoire de ton bundle. Tu n'es évidemment pas limité aux répertoires "Entity", "Form", etc. Si ça te chante tu créé un sous répertoire Toto avec un objet qui fait une tâche X comme parser un fichier etc.

En résumé :
Dans la classe de base de ton Bundle, tu ne mets du code que lié à l'injecteur de dépendance. (Ne t'inquiète pas si tu n'as pas de code dans cette classe, c'est tout à fait normal).
Dans tes contrôleurs, tu mets le code qui gère les interactions des utilisateurs. Par exemple, affichage/soumission d'un formulaire pour créer/modifier une entité X.
Si tu as des tâches un peu plus globales, tu fais des services. C'est à partir du moment où tu fais des services que tu vas commencer à mettre du code dans ta "classe Bundle", en particulier si ces bundles sont destinés à être distribués.

Si je ne suis pas assez clair ou si tu as d'autres questions, fais le moi savoir.

Un petit post pour vous signaler la sortie en version stable de Symfony2
 
http://symfony.com/blog/symfony-2-0

Merci Tirkyth pour ton retour

J'ai vu ça , je pense que ce serait bien qu'il y ait au moins un topic (si ce n'est un forum) pour Symfony 2...

Dans ce cas, si les autres participants de ce topic peuvent donner leur avis sur le fait de faire ou non un topic dédié à Symfony2.
 
Si tout le monde pense que ça peut être utile, peut-être que j'en commencerai un. Ou si quelqu'un d'autre s'en charge, je l'aiderai à rédiger un premier post assez clair et précis sur les features importantes du framework.

Peut être que le plus simple serait de reprendre ce topic, non ? 

Ben tu as des gens qui utilisent la version 1.4, et ceux qui souhaitent utiliser la 2. A partir de là les questions seront différentes, je pense que ça risque d'être assez difficile à suivre si on a pas un topic séparé.

Pour ma part, je découvre cette version 2, et la doc n'étant pas encore assez exhaustive, j'ai pas mal de questions, et les forums dédiés à cette nouvelle mouture de Symfony ne sont pas légions...

Il suffit de le préciser quand on pose une question
 
il n ' y a pas tant d'activité que ça non plus.

En effet l'activité n'est pas énorme sur ce topic, je pense que mêler les deux versions dans un seul topic ne gène pas la lisibilité tant qu'on pense à bien préciser la version utilisée dans les questions.

Très bien dans ce cas, je me lance. Et j'ai une petite question justement

J'ai souhaité créer un formulaire basé sur l'objet FormBuilder de Symfony 2. Jusque là pas de soucis. Ca s'est compliqué au moment ou j'ai voulu modéliser dans le formulaire un relation de type ManyToMany.

De ce que j'ai lu sur la doc, il faut utiliser un FieldType de type CollectionType

http://api.symfony.com/2.0/Symfony [...] nType.html

Le problème c'est que le rendu donne un truc du genre :

Et je ne sais pas trop comment l'exploiter si ce n'est en JS...
Edit : En fait il s'agit de l'une des nouveautés de HTML5 la gestion de ces nouveaux attributs de balises

Ensuite, j'ai également lu que l'on pouvait mettre les labels souhaités pour chaque entrée du formulaire (Via la méthode configure de la class qui étends Symfony\Component\Form\AbstractType)
Edit : JE veux dire qu'on passe un tableau d'option du type :

Seul souci, cette méthode ne prends en paramètre qu'une instance de Symfony\Component\Form\FormBuilder. Et il est impossible d'avoir depuis cette méthode un accès au service de traduction.

D’où ma seconde question comment faire, car je ne veux pas déclarer mon formulaire depuis le contrôleur...

Merci de votre aide

En effet, ce ne sont que des ajouts liés au HTML5. Tu n'as pas à les exploiter sauf si tu en as envie/besoin.
Du coup est-ce que tu as toujours une question liée à ça où est-ce que ton formulaire se comporte correctement ?
 

Si tu fais un rendu de ton formulaire de façon correcte, c'est à dire via les fonctions Twig form_rest, form_row, form_widget, etc, alors tu n'as pas besoin de te soucier d'appeler toi même le service de traduction. Ces fonctions le font pour toi.
Si, pour un champs donné, tu as passé comme options :

array('label' => 'Mon label')

Alors Twig va faire un rendu d'un tag label, et pour l'affichage de la chaîne de caractère il va faire pour toi :

Donc tu as juste a bien configurer ton service de traduction et mettre en place les traductions.

Si tu veux, j'ai fait un truc tout con, à savoir, une table d'utilisateurs, et une tables de rôles pour ces utilisateurs, et entre les deux une table de relations ManyToMany.

Là je veux juste faire un formulaire ou tu créé un utilisateur, en lui associant des rôles. C'est absurde certes, mais je veux juste voir comment ça tourne j'ai pas de but particulier, si ce n'est voir comment fonctionne en ce qui concerne les relations N <-> N.

Si tu veux, le fait que ça me sorte un div avec cette propriété (data-prototype) ne me gène pas mais je suis plutôt surpris, mais je m'attendais plutôt à un liste de checkbox en fait. En l'état je ne vois pas ce que je dois faire avec ce div, qui par ailleurs contient bien les bonnes données, mais htmlentitisé au sein de l'attribut data-prototype.

Je vais donc supposer que tu as correctement fait ta relation dans tes entités.
Est-ce que tu peux poster le code de ta classe de formulaire, ainsi que le template qui l'affiche ?

Bien sur

Je vais zapper les propriétés qui ne sont pas relatives à cet exemple.

Voici le rendu retourné par le widget pour la propriété userRoles, le reste fonctionne à merveille. Je précise que j'ai fait un form_rest classique depuis un template Twig :

L'entité User :

L'entité UserRole:
En gros ca contient les statuts utilisateur, admin, et super admin

Le Form Type UserRole :

Et pour finir la class UserRoleType:

Tu es en quelle version ? 2.0.0 ? Moi j'ai un exemple qui fonctionne comme tu le souhaites que j'ai sur une 2.0 RC6, mais je pense qu'il doit fonctionner sur une 2.0.0.
Si tu es sur une version plus ancienne, je te suggère de te mettre à jour.
 
J'ai beaucoup moins de code que toi par contre.
Je n'ai essayé qu'un contexte hors sécurité c'est à dire sans l'implémentation des diverses interfaces.
 
(J'ai enlevé les use et namespaces etc)
 
Les entitiés :

/**
 * @ORM\Entity
 * @ORM\Table(name="product" )
 */
class Product
{
    /**
     * @ORM\Id
     * @ORM\Column(type="integer" )
     * @ORM\GeneratedValue(strategy="AUTO" )
     */
    private $id;
 
    /**
     * @ORM\Column(name="name", type="string", length=255)
     */
    private $name;
 
    /**
     * @ORM\ManyToMany(targetEntity="ProductCategory" )
     * @ORM\JoinTable(name="product_has_product_category",
     *      joinColumns={@ORM\JoinColumn(name="product_id", referencedColumnName="id" )},
     *      inverseJoinColumns={@ORM\JoinColumn(name="product_category_id", referencedColumnName="id" )}
     * )
     */
    private $categories;
 
    public function __construct()
    {
        $this->categories = new \Doctrine\Common\Collections\ArrayCollection();
    }
 
    // [...] Getters and setters
}

/**
 * @ORM\Table(name="product_category" )
 * @ORM\Entity
 */
class ProductCategory
{
    /**
     * @var integer $id
     *
     * @ORM\Column(name="id", type="integer" )
     * @ORM\Id
     * @ORM\GeneratedValue(strategy="AUTO" )
     */
    private $id;
 
    /**
     * @var string $name
     *
     * @ORM\Column(name="name", type="string", length=255)
     */
    private $name;
 
    public function __toString()
    {
        return $this->name;
    }
 
    // [...] Getters and setters
}

[/code]
 
Ma classe de formulaire :

class ProductType extends AbstractType
{
    public function buildForm(FormBuilder $builder, array $options)
    {
        $builder
            ->add('name')
            ->add('categories')
        ;
    }
 
    public function getName()
    {
        return 'storebundle_producttype';
    }
}

 
Tu vois, quasiment rien à faire normalement. Ce que je te suggère : Supprimer la classe UserRoleType car à priori elle ne sert à rien.
Dans UserType: supprimer ta méthode getDefaultOptions pour le moment. No need
Dans UserType, remplacer :

->add('userRoles', 'collection', array(
        'type' => new UserRoleType(),
        'allow_add' => true,
    )

Par:

->add('userRoles')

Je teste ça ce soir, et je te dirai si la magie a opéré
Pour te répondre je suis sur la 2.0.0 dernière en date, et vendors à jour.

Bien que ta syntaxe soit plus concise et la mienne plus verbeuse, je ne vois pas en quoi elles diffèrent... (Enfin, ca a l'air de faire la même chose)

Graphiquement tu obtiens quoi comme rendu, et sous quel navigateur ? (P'tit screenshot inside ? )

La différence c'est que moi je lui laisse le soin de "deviner" le type de champ approprié pour gérer mon association many to many, alors que toi tu lui dis "mets-moi un champ collection".
 
Or, quand il va essayer de deviner il ne va pas mettre un champs de type collection mais un champ de type entity en fait.
 
Il va tomber sur ça précisément :

class ProductType extends AbstractType
{
    public function buildForm(FormBuilder $builder, array $options)
    {
        $builder
            ->add('name')
            ->add('description')
            ->add('isVisible')
            ->add('treemap')
            ->add('categories', 'entity', array(
                'class'     => 'Acme\\StoreBundle\\Entity\\ProductCategory',
                'multiple'  => true,
            ))
        ;
    }
 
    public function getName()
    {
        return 'storebundle_producttype';
    }
}

 
La différence vient de là je pense. Visuellement sur Firefox 5, j'obtiens ça :

 
Il suffit alors de rajouter un "expanded => true" en option pour obtenir une liste de checkboxes :

class ProductType extends AbstractType
{
    public function buildForm(FormBuilder $builder, array $options)
    {
        $builder
            ->add('name')
            ->add('description')
            ->add('isVisible')
            ->add('treemap')
            ->add('categories', 'entity', array(
                'class'     => 'Acme\\StoreBundle\\Entity\\ProductCategory',
                'multiple'  => true,
                'expanded'  => true,
            ))
        ;
    }
 
    public function getName()
    {
        return 'storebundle_producttype';
    }
}

 
Et tu obtiens ce que tu souhaitais :

J'espère que tu n'as pas fait ça juste pour me montrer

En fait j'avais vu sur le net qu'on pouvait aussi faire ça de façon moins native en prenant un champ de type entity, mais en fait après j'avais eu une erreur comme quoi il avait reçu un instance de class Doctrine ArrayCollection au lieu d'un objet UserRoles (Logique) quand je le déclarait explicitement.

Je crois peut-être à tort, que laisser Symfony gérer à un cout en ressource tout de même, aussi minime soit-il, mais je me dit qu'il n'y a pas de petites économies

Je viens de tester, et si je laisse Symfony gérer, j'ai bien le même rendu que toi

Cependant, je suis quand même désireux de savoir comment le faire en le déclarant explicitement, histoire de savoir comment ça doit se configurer
Edit: pour le expanded, j'avais vu Je me suis quand même farci la doc, mais j'ai juste pas pensé à essayer de laisser Symfony gérer comme un grand

Mon dernier exemple justement est une déclaration explicite dans la classe de formulaire. J'ai mis par contre un champs de type "entity", et je ne suis pas tombé sur l'erreur que tu décris.
Je veux bien d'ailleurs que tu explicites le "de façon moins native en prenant un champ type entity".
En quoi est-ce moins natif ?

Par moins natif, je veux parler de gens ayant traité ce cas en ayant recours à un ChoiceType, et en donnant la liste des valeurs dans le tableau options, tout en ayant pris soin de rajouter le nom de la dite option dans la liste des options reconnues pour ne pas bouffer une exception...

Je reviens avec une nouvelle question

Je souhaiterais utiliser les assets, et plus particulièrement les "minify". Mais je ne vois pas ce comment je suis censé afficher le chemin vers une image de mon bundle située dans ProjetTestBundle/Resources/public/images/monimage.png

alors j'ai naivement fait le code suivant :

Mais on dirait que ce n'est pas "interprété"... Et niveau doc pour le moment...

Z'auriez une idée ?

Merci, j'avais vu cette syntaxe, mais je la trouve autrement plus verbeuse qu'utiliser un bon vieux :

Mais bon, si c'est la façon la plus clean de faire, merci de la confirmation.
 
Autre chose, avant d'utiliser les assectics pour la gestion des JS et CSS, j'avais pas de soucis pour les images qui étaient utilisées depuis les CSS :
 
Par exemple dans mon CSS @ProjetTestBundle/Resources/public/css/style.css:
 

 
L'image étant dans @ProjetTestBundle/Resources/public/images/monimage.png.
 
Hors, désormais ces images ne sont plus affichées puisque le path du CSS généré par les assetics utilise les réécritures d'URL...
 
Ma question est donc, y a t-il quelque chose que j'ai oublié d'implémenter ?
 
Ou bien dois-je utiliser un template CSS twig, et déclarer mes images avec une balise {% image %} ?
 
Si je suis pas clair dites le moi

Salut, j'ai une question symfony 1.4 :
 
Je suis dans un Task, destinée à être appelé en CRON, je passe en param l'application et l'environnement mais j'ai pas de contexte.
 
j'obtiens le fameux :  

 
J'ai donc fait un :
 

 
C'est le Bien ou c'est le Mal ?
 
En effet, j'ai besoin d'accéder au Dispatcher et aussi au Logger dans une classe dans un plugin (qui hérite de sfWebBrowser).
 
Que faire de mieux et comment contourner les sfContext::getInstance()->getLogger() et autre sfContext::getInstance()->getEventDispatcher()
 
Pour l'event dispatcher, je crois avoir trouvé qu'on peut le choper dans l'objet appli mais pour le logger, je trouve pas.
 
Thanx

L'objet task a un logger il me semble.

Ou alors c'est le dispatcher qui en a un.

Sinon initialiser le contexte globalement c'est mal mais ça m'arrive des fois

En fait c'est surtout le côté Singleton qui est mal à la base.

Disons que ça a ses avantages, et ses inconvénients, ça te permet  d'accéder à peut prêt tout et de n'importe où, tout en étant assez libre (si j'ose dire) dans l'architecture du dev, prenant un minimum de RAM.
 
La contrepartie, et c'est le cas dans ma boite, c'est que tu n'as plus de contrôle sur qui modifie quoi et quand... Et que quand tu veux faire évoluer un truc, et bien comme tu n'as pas de contrôle sur tes objets parce que plutôt que de passer les objets en arguments, ce qui est fait est un appel a une bonne grosse fonction globale...
 
C'est une des raisons pour lesquelles j'apprécie la façon dont Symfony 2 a été modélisé

Tous les trucs crades ont leurs avantages
 
Et le même inconvénient, qui est que tu t'en mords souvent les doigts au bout de quelques mois

Oui je suis bien d'accord avec le côté obscur du singleton
 
En fait, c'est le rôle/définition même du sfContext où j'ai du mal.  Autant pour la sfAppli, l'env, la config ou la route je vois bien, autant le contexte, je vois pas le rôle technique d'un tel objet et pourquoi il ne serait pas instancié en CLI quand on spécifie une appli.  
 
Y a une subtilité qui m'échappe.
 
Sinon, l'objet task n'a pas de logger mais une méthode (qui dispatche un "command.log" )
 
Je pense que je vais virer les log de mon plugin (ou checker hasInstance() avant) et récupérer le dispatcher par un ProjectConfig::getActive()->getEventDispatcher().  
=> Quitte à utiliser un singleton, autant que ça marche même en CLI
 
Merci pour ta réponse
 
Edit : Autre solution qui me vient après coup, vu que je suis dans un plugin, est-ce que je ne peux pas initialiser le context ou passer le dispatcher dans l'init du plugin ?

Toujours dans mon tour de découverte Symfony2, la en fait je suis plus sur une problématique Twig, mais je me dis que ceux qui se mettent sur Symfony 2 se mettrons probablement à Twig...
 
J'essaye de faire une liste. Basée sur les résultats retourné par un Respository Doctrine. Jusque là, rien de bien compliqué me direz vous.
 
Seulement voilà, dans l'idée de faire les choses bien, je souhaite faire ça via une extension Twig.
 
Le pager aurait pour rôle de gérer et restituer la pagination de la liste, la persistance des filtres dans la session, etc...
 
L'extension existante la plus proche de ce que je veux faire est je pense {% form_theme %}
En effet, cette balise rempli le template en déclarant le contenu de certains blocs (Je fais référence aux blocs de widgets)
 
l'idée ce serait donc de pré remplir des blocs genre "pagination" qui seraient déclarés dans un fichier, et qui serait appelé de la même façon que lorsqu'on appelle {% form_theme from "chemin_du_template" %}
 
Des pistes ? Car je ne crois pas que cette fonctionnalité existe...

Est-ce que tu ne peux pas te servir des macros de twig pour arriver à ce résultat ?
 
http://www.twig-project.org/doc/templates.html#macros

Si... Effectivement, ca m'a l'air pas mal, je me demande même pourquoi je n'y ai pas pensé plus tôt

Le pire c'est que je suis passé dessus quand je me suis fait la doc, mais entre Doctrine, Twig, les Controller, les Firewalls, les Assetics, etc... Je suppose que je l'ai oublié celui-là

Merci pour ce rappel
Effectivement ca sera bien plus simple et à mon avis plus performant

En tout cas, si ça répond au besoin alors il n'est pas nécessaire de se mettre à faire une extension Twig.
 
Si jamais en essayant tu te rend compte que les macros ne sont pas suffisantes, on essayera de trouver une autre solution.

D'après ta signature je lis que tu bosses pour Sensio Labs, ça doit être sympa de bosser sur un truc récent et de ne pas s'encombrer de la maintenance de vieux bousins en PHP 3 ou 4...

Pour en revenir à ce dont on parlait, normalement les macros devraient suffire, cependant je découvre toujours comment ça marche, je ne me suis pas encore approprié complètement la logique de fonctionnement de SF2.

Après, ce serait plus pour une question de curiosité personnelle, mais c'est toujours intéressant de savoir comment faire une extension Twig...
Et encore, Il y a les extensions, les Nodes, j'ai pas encore tout capté mais ça viendra en temps voulu

De ton ressenti par rapport à toutes les façons de configurer une application (Kernel, Bundles, etc...), tu es plus sur le PHP, le YAML, le XML ou les annotations ?