3

After reading a lot about Symfony2 DIC and Semantic Configuration, I've asked myself: "So, now how do have I to procede for reach what I'm trying to reach!?"

Scenario

Imagine you want to create a service that is pretty like a "admin dashboard dispatcher".
This means that I have some entities that I want to do CRUD on. What I don't want to do is a combination of route->action->logic for every entity in my project; that's because, in that way, I'll have to write for each object something like:

  • /add/entity
  • addEntityAction
  • entityLogic

where "entity", of course, is the name of entity in object.

I'm building up a service (like a dispatcher) that will respond on action (add-delete-edit) but that is parameterized: I'll write onto address bar something like /add/entityA or /add/entityB and that routes will lead me at the same action (of course) were I recall my service with entity name.
At this point, my service, should be smart to know what is EntityClass, FormTypeClass and template file for the entity in object.

And here comes my mental chaos

I have to do something preliminaries configurations like following php array (this is only an example)

array(
'EntityA'=>array(
  'class'=>'BundleName/Entity/EntityA',
  'form'=>'BundleName/Form/entityAType',
  'template'=>'EntityATemplate'),
'EntityB'=>array(
  'class'=>'BundleName/Entity/EntityB',
  'form'=>'BundleName/Form/entityBType',
  'template'=>'EntityBTemplate'),
[...]
);

or something equivalent.

BUT ....

What is the best practice, for this scenario, taking into account that only me and my team will use this bundle (so isn't a third-part bundle)?

First solution

Use a parameters.php file were I define some constant or static members

Second solution

Use a map (like previous array) directly into my service

Third solution

Use semantic configuration for my bundle, defining an Extension class and so on

If I have to be honest, I can't say what is better. Obviously first one and third one are better that second one.
First solution broke up symfony2 philosophy but seems the only way because the second one, seems to be useful only if I have to trigger up creation of some services (in cascad fashion) that are handled directly my DIC, or for have configuration hierarchy, or for merge more that one configuration file, or (maybe the most importat for third party bundle) for make some kind of validation on config. file

What's your opinion? Do you see some other methods for do this, or do you simply prefer third solution? I want to know your opinions.

Edit: Obviously I can use builder injection or setter injection, but I consider it into "DIC" section (so, third solution)

Community
  • 1
  • 1
DonCallisto
  • 29,419
  • 9
  • 72
  • 100
  • what's with [Sonata Admin](http://sonata-project.org/bundles/admin/2-1/doc/index.html) – Emii Khaos May 13 '13 at 12:32
  • @Pazi: nope, i'm writing (and want to write) it from scratch. I've already tried with sonata admin and it isn't flexable for my needs – DonCallisto May 13 '13 at 12:40

1 Answers1

0

If you want to do it the Symfony way, I'd suggest using a configuration (if I understood it correctly):

acme_foo:
    entities:
        FooEntity:
            class_type: Acme\FooBundle\Entity\Foo
            form_type: Acme\FooBundle\Form\Type\FooType
            template: AcmeFooBundle:Entity:foo.html.twig
        BarEntity:
            class_type: Acme\FooBundle\Entity\Bar
            form_type: Acme\FooBundle\Form\Type\BarType
            template: AcmeFooBundle:Entity:bar.html.twig

Using the the AcmeFooExtension class you can set the container parameter which contains the configuration. You can then inject this into your service (which is an event listener). When /add/Foo is called you can dispatch a acme_foo.entity_add event which is consumed by the listener.

The thing you should remember is that everything you can put into a config.php or parameters.php file can be put into the app configuration (config.yml).

Ramon Kleiss
  • 1,684
  • 15
  • 25
  • Yes, this is third solution. Is DIC and semantic configuration, so I've already consider it. What I want to know is why do you suggest this and not another way – DonCallisto Apr 16 '13 at 15:18
  • Both testability and flexability highly increase using dependency injection. And the bundle system is designed to be reused (not even by third parties). – Ramon Kleiss Apr 16 '13 at 16:30
  • If I use an external file, like a configuration file, flexability is granted also. I suppose that DIC should be used for other issues – DonCallisto Apr 16 '13 at 17:15
  • That is of course completely true, but how will you load that without a hard dependency? `require_once __DIR__.'/../../../app/parameters.php` doesn't look very nice. You could of course use the `kernel.root_dir` but even then, it's a hard dependency and even then, you're basically copying the functionality of the `Container` without the same flexibility or testability. – Ramon Kleiss Apr 16 '13 at 21:27
  • No, for configuration file I don't use require_once (as symfony2 doesn't work in that way) but `use` directive so, once bundle is registered, is pretty straightforward – DonCallisto Apr 17 '13 at 07:22
  • You still lose the testability of the entire class if you take that approach. But if you don't intent to unit test the code, it's a perfectly fine approach (but I wouldn't recommend it). – Ramon Kleiss Apr 17 '13 at 23:01