Créer une BaseEntity comme dans les bundles FOS

**mediaphragm** · 03/08/2011, 21h35

Bonsoir à tous,

Voilà j'ai créé un service et j'essaye de créer une entité de base que les utilisateurs devront étendre en créant une entité dans leur bundle (comme dans le FOSUserBundle en fait).

Si j'ai bien compris le fonctionnement :

1. Je crée un Model dans MonBundle\Model en abstract
2. Je crée une entité dans MonBundle\Entity en abstract qui étend le Model
3. Dans un bundle différent, je crée une entité qui étend l'entité au point, et celle-ci doit contenir un champ id.

Apparement il doit me manquer qqch, car quand je fais un generate:entities + schema:update dans le bundle Demo de la SE, je n'ai que mon champ id qui se met en bdd.

Si qqun pouvait m'éclairer, ce serait cool

Je vous met ici mes codes au cas où:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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
 
<?php
//Model
namespace Mediaphragm\VisitorsBundle\Model;
 
abstract class Visitor
{
	protected $id;
 
    /**
	* @var string
	*/
    protected $username;
 
    public function __construct()
    {
 
    }
 
	/**
	* @return string
	*/
    public function getUsername()
    {
        return $this->username;
    }
}

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
<?php
//Entity
namespace Mediaphragm\VisitorsBundle\Entity;
 
use Mediaphragm\VisitorsBundle\Model\Visitor as AbstractVisitor;
 
abstract class Visitor extends AbstractVisitor
{
}

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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
 
<?php
//Entité dans le bundle Demo qui doit étendre mon bundle
namespace Acme\DemoBundle\Entity;
 
use Mediaphragm\VisitorsBundle\Entity\Visitor as BaseVisitor;
use Doctrine\ORM\Mapping as ORM;
 
/**

 * @ORM\Entity
 * @ORM\Table(name="mediaphragm_visitors")
 */
class Visitor extends BaseVisitor
{
 
    /**
     * @ORM\Id
     * @ORM\Column(type="integer")
     * @ORM\GeneratedValue(strategy="AUTO")
     */
    protected $id;
 
	public function __construct()
	{
		parent::__construct();
	}
 
    /**
     * Get id
     *
     * @return integer 
     */
    public function getId()
    {
        return $this->id;
    }
}

**Nek.dev** · 04/08/2011, 00h48

Salut,

Je ne suis pas un expert, mais voici mon avis sur la chose:
Mettre des classes dans bundle/model c'est inutile. Pourquoi faire des classes d'entité vides ? Bref je trouve bien mieux de directement les mettre en entité. La seule chose est qu'elles ne seront pas abstraites. Mais après tout pourquoi devraient-elles l'être ?

Pour ce qui est de ton problème c'est tout simplement parce que sur FOSUserBundle les champs ne sont pas définis en annotations mais en XML. C'est pour cela qu'il n'y a pas d'annotations dans la classe abstraite ;-) .

**winzou** · 04/08/2011, 05h23

Envoyé par Nek.dev

Je ne suis pas un expert, mais voici mon avis sur la chose:
Mettre des classes dans bundle/model c'est inutile. Pourquoi faire des classes d'entité vides ?

Pour pouvoir gérer Entité et Document. FOSUB utilise un model car il laisse le choix du type de stockage au dev final.

Donc effectivement si tu n'as pas besoin de cette flexibilité, pas besoin de passer par un model. Tu aurais une entité qui ressemble à ca : https://github.com/winzou/BookBundle...tity/Entry.php Puis dans ton bundle tu hérites de cette classe comme tu le fais avec celle de FOSUB.

**mediaphragm** · 04/08/2011, 08h14

Tout à fait Winzou, même si dans un premier temps ce n'est pas une priorité pour le bundle de pouvoir travailler aussi bien en odm/orm/couchdb, ce serait bête de ne pas partir sur une base flexible directement.

J'ai pour finir réussi à faire fonctionner la génération, il s'agissait d'une erreur de type dans mon metadata (je ne suis pas encore tout à fait familiarisé avec le xml

)

++

**Nek.dev** · 04/08/2011, 14h59

Si tu galères avec le xml essaie de voir avec le yaml. (oui, c'est plus simple je trouve ^^)

**mediaphragm** · 04/08/2011, 15h49

Oui je trouve aussi, mais ce bundle peut se retrouver en public, donc comme préconisé par sf, c'est en xml.

**Nek.dev** · 04/08/2011, 16h30

Ah bon c'est préconisé le xml ? Je pensais que c'était le yaml, t'as un lien ?

**winzou** · 04/08/2011, 16h52

C'est pas spécialement préconisé, mais c'est plus interopérable (plus d'outil lisent le xml que le yml). En pratique le xml est vraiment illisible, c'est se tirer une balle dans le pied que de l'utiliser.

**mediaphragm** · 04/08/2011, 23h09

Ah bon c'est préconisé le xml ? Je pensais que c'était le yaml, t'as un lien ?

Ici un article traitant des services, qui pour moi est aussi valable pour les entités dans les services : http://fabien.potencier.org/article/...cribe-services

Ici dans la doc: http://symfony.com/doc/current/cookb...extension.html
The second method has several specific advantages:

Much more powerful than simply defining parameters: a specific option value might trigger the creation of many service definitions;
Ability to have configuration hierarchy
Smart merging when several configuration files (e.g. config_dev.yml and config.yml) override each other's configuration;
Configuration validation (if you use a Configuration Class);
IDE auto-completion when you create an XSD and developers use XML.

**dourouc05** · 04/08/2011, 23h15

Envoyé par mediaphragm

IDE auto-completion when you create an XSD and developers use XML.

Ce n'est pas impossible autrement, cependant : il suffit d'avoir le plug-in qui va bien pour ça, comme pour tout langage. Sinon, ce n'est pas vraiment un avantage suffisant à mes yeux pour pousser à utiliser du XML au lieu du YAML : seuls de vrais fous passent leur temps à écrire du XML sans aide, les autres utilisent du YAML (ou autre).

**mediaphragm** · 04/08/2011, 23h34

seuls de vrais fous passent leur temps à écrire du XML sans aide

Voilà un extrait du premier document:

What's the best Format for your Service Definitions?

Using the XML format gives you several advantages over the YAML one:

When a XML file is loaded, it is automatically validated with the built-in services.xsd file;

The XML can be auto-completed in IDEs;

The XML format is faster than the YAML one;

The XML format as no external dependencies (the YAML format relies on the sfYAML component).

**dourouc05** · 04/08/2011, 23h49

Envoyé par mediaphragm

Voilà un extrait du premier document:

Pourtant, quand un YAML contient des erreurs, Symfony2 pousse une gueulante (à voir jusqu'où est poussée la vlidation ; cependant, dès qu'il y a quelque chose de bizarre, ça fait une erreur en dev, donc obn

) ; il y a un format encore plus rapide : le PHP (vu qu'on se base sur le moteur d'analyse de l'exécutable, pas d'appel supplémentaire vers l'extérieur, fichier plus léger à charger, etc.). Donc bon !

**winzou** · 05/08/2011, 04h49

mediaphragm attention à ne pas nous sortir des post valable pour symfony premier du nom :p
Les yaml sont validés également. Le yaml n'est pas autocomplété... parce qu'il n'en a pas besoin ! Le XML et le Yaml et le PHP sont exactement équivalent niveau perf, car mis en cache. Le composant sfYaml n'existe plus sous Symfony2 :-°

Créer une BaseEntity comme dans les bundles FOS [2.x]

Symfony PHP

Discussions similaires

Partager

Partager