Event driven design

[sebastianblum]

With symfony 2.0, I had a lot of problems with the event driven design.

I took a long time until I understand the benefit of using the event dispatcher.

in my opinion, in the symfony best practices, there should exist a good example how to use the event dispatcher.

The controller listener is needed, but not a good example.
https://github.com/symfony/symfony-demo/blob/master/src/AppBundle/EventListener/ControllerListener.php

maybe we can add an example like this
https://github.com/symfony/symfony-demo/blob/master/src/AppBundle/Controller/BlogController.php#L64
the controller can be reduced, if we dispatch a new.user event and add at least one event listener who is persisting the data to the database and maybe another one, which is doing something else.

there exists a lot of blog articles about thin controller, maybe we should try to implement a good case in the symfony demo.

what do you think about that?

[wouterj]

While I really really like Event Driven Design, I don't think it's good to add it to the best practices. For the same reason as adding DDD or the decouple-from-the-framework approach isn't a good fit for the best practices.

Keep in mind that the best practices are for beginners, for people that are new to symfony and want to learn a quick way of using Symfony. With bad wording, it's like the RAD practices for Symfony.

[94noni]

-1, yes I think it is a good practices but not for this demo app which is for new comers

[javiereguiluz]

I'm divided in this. I agree with @wouterj and @94noni that this may be too much ... but I also agree with @sebastianblum and I'd like to see more useful examples related to the event dispatcher.

Although this application is aimed at newcomers, I'd like to show at least one example of how to do "everything" with Symfony.

[sebastianblum]

DDD is clear that the separation of business logic and symfony should not be part of the best practices.

in my opinion, event driven design is one of the best features in symfony and it is difficult to learn for beginners. If the beginners don't understand event driven design by seeing the code for the first time, the best practices shows the possibility.

I would vote for integration event driven design and thin controller examples in the best practices demo code.

wish you happy eastern.

[b-durand]

We can use branch to have a level beginner and mid level.

[javiereguiluz]

@b-durand I'm afraid that maintaiing two different branches for beginners and experts is something we cannot consider at the moment. It would be to hard to maintain.

[weaverryan]

+1. Why not make sure we have something like this in the docs? I don't see any reason why a cookbook couldn't have a link to a GitHub repo with the code that goes along with it (in fact, I think this is something we should think about doing in the docs). Then we can keep the demo simple, but have other example projects.

[voronkovich]

As an example of an event driven design I would suggest to create simple LastLoginListener like this one in the FOSUserBundle: https://github.com/FriendsOfSymfony/FOSUserBundle/blob/master/EventListener/LastLoginListener.php. It would be simple and easy to understand for beginners.

[ogizanagi]

As the demo application should keep things simple for beginners and focuses on best practices, we thought eventually about creating a new "advanced demo application" (somehow installable through the Symfony installer as well).
Then users can rely on those examples conjointly with the cookbooks for more advanced usage of the components within the Symfony Standard Edition.

We'd like to start with advanced form usages by covering most of the commonly encountered problematics while developing an application (Form themes, FormEvents, DataTransformers, ajax forms, ...). But it would actually not be restrained to the form component.

What do you think of such a demo application ?

[voronkovich]

@ogizanagi, I think it's a great idea.

[b-durand]

@ogizanagi 👍 take care of beginners is good, but missing "commonly encountered problematics".

[weaverryan]

@ogizanagi My worry is maintenance - i.e. who will create this and maintain it? But I'm very interested in this idea. To go further, I'm interested in having cookbook articles about this kind of stuff that is actually backed by annotated project code (e.g. "Go and see the code for this cookbook article here: http://"

[ogizanagi]

@weaverryan : Sorry for the late answer. I didn't see your comment before.

The idea is to provide a fully working "real-life" symfony application (like the current demo, but with intensive use of the components), along with some comments in the code and short articles explaining each of the components aspects it involves.
So, I don't think maintenance will be a main issue, as everyone would be able to contribute in order to enhance the articles, but suggestions about new "features" will be quite limited once we have a proper codebase. The maintenance cycle will not be as complex as for a component either.

That's something we recently talked internally and with @webmozart. I started this week and will certainly keep improving it on my time. The codebase currently involves samples for the following elements:

• Forms:
  • FormEvents: Build dynamic forms according to submitted values, filtering submitted data, … However, as we do not create those events ourself, nor injecting and using the dispatcher, it's not a sufficient example to demonstrate the usages of the EventDispatcher component.
  • Ajax forms.
  • DataTransformer.
  • Custom form types (and form as services).
  • Some scenarii involving form options usages like inherit_data, property_path, mapped, allow_extra_fields, disabling validation, ...
  • Form themes: use a form theme for a specific field in a template, create & use at the application level form themes for our custom types, overriding an existing form theme, ...
  • GET forms scenarii (search, filters, ...)
  • Use HTTP Methods beyond GET and POST.
• Doctrine:
  • Entities (mapping, relations, ...).
  • Doctrine inheritance.
  • Custom DBAL Type.
  • Doctrine extensions.
  • Data Fixtures (+ nelmio/alice).
• DependencyInjection:
  • Services declaration.
  • CompilerPass (replace a service class by ours)
• Twig:
  • Extensions, Globals, ...
• Assetic.

However, we cannot offer through this idea something as efficient as you could have in a lesson with a dedicated exercise, nor having parts of the application dedicated to illustrate a symfony.com cookbook. Because isolating and finding "features" for each of the components capabilities in a real-life application is quite complex :/ .
For instance, one of the forms already involves the major part of the elements I mentioned above and is a big piece. One of the main challenge then, is to isolate as much as possible anything in order to make it understandable with a little investment by the developer.
But I think intermediate to advanced developers would be pleased to have a working application to play with in order to better understand Symfony components (and third-party ones !).

[stof]

I'm -1 for using entity inheritance in the demo project. Entity inheritance is something that all Doctrine recommend to avoid. It comes with many drawbacks (many of them related to performance), so we should not encourage using it. There are cases where using this feature is valid, but in most cases, it is a bad idea.

[javiereguiluz]

@stof thanks for commenting on this. I didn't know that inheritance was so discouraged. In fact, the Doctrine documentation doesn't say anything about that. I've created a PR to the Doctrine docs: doctrine/orm#1486

[javiereguiluz]

Let's close this because since it was created, we've added a ton of features, including event listeners, subscribers and most of the features that @ogizanagi outlined.