Answers.Body: <p>You must be digging pretty deep if you're running into Symfony. Its introduction into the stack is fairly new. CiviCRM has been around for over ten years, so some of the technologies are pretty hip and new (like Symfony) and some of the technologies, like Smarty or PEAR DB... well, not so much.</p>
  
  <p>I think I've run into Symfony in some code around events (like... programming events, not CiviEvents) and maybe in some of the new command line tools. If your primary concern is fixing bugs, you may never even see it, as many of the bugs tend to live in older code.</p>
  
  <p>Bottom line: It's a technology the core team would like to adopt, but adoption is happening slowly. I wouldn't say that Symfony experience is a prerequisite for developing CiviCRM any more than AngularJS experience is.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-02-01T08:14:00.857Z
Answers.Text: I like it deep @GinkoFJG
Answers.UserDisplayName: ErichBSchulz
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-01-31T20:47:17.697Z
Answers.LastActivityDate: 2017-01-31T20:47:17.697Z
Answers.UserDisplayName: universalhandle
Answers.Body: <p>Those are the three that we use now, although I'd usually prefer to read the guides rather than the autogenerated API docs, i.e.</p>
  
  <ul>
  <li><a href="http://symfony.com/doc/2.7/service_container.html">Symfony Service Container</a></li>
  <li><a href="http://symfony.com/doc/2.7/components/event_dispatcher.html">Symfony Event Dispatcher</a></li>
  <li><a href="http://symfony.com/doc/2.7/console.html">Symfony Console</a></li>
  </ul>
  
  <p>This blog from <code>civicrm.org</code> is probably relevant: <a href="https://civicrm.org/blog/totten/the-static-is-dead-long-live-the-static">The static is dead. Long live the static!</a></p>
  
  <p>To date, most of the Symfony usage has been internal -- e.g. <code>Civi\Core\Container</code> originally followed a... radically minimalist approach (verging on antipattern) by putting all the service definitions in one PHP file. But it's starting to open up a bit for downstream dev:</p>
  
  <ul>
  <li>v4.7 introduced <code>hook_civicrm_container</code></li>
  <li><code>cv</code> recently added subcommands for <code>debug:container</code> and <code>debug:event-dispatcher</code></li>
  </ul>
  
  <p>However, I don't regard it as consumer-friendly right now because all service-definitions and event-listeners are declared in PHP code. I'd really prefer (a) bindings for YAML/JSON/XML files and (b) some kind of autowiring for the dependency injection.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-02-01T04:48:22.160Z
Answers.LastActivityDate: 2017-02-01T04:48:22.160Z
Answers.UserDisplayName: Tim Otten
Body: <p>I'm bit of a CiviCRM noob, but I'd like to help out and fit with the current patterns. I keep encountering bits of <a href="http://symfony.com/">Symfony</a> in core code and it seems well respected... and pretty cool.</p>
  
  <p>So far I have identified these in the core:</p>
  
  <ul>
  <li><a href="http://api.symfony.com/3.1/Symfony/Component/DependencyInjection.html">Dependency Injection containers</a></li>
  <li><a href="http://api.symfony.com/3.1/Symfony/Component/EventDispatcher.html">Event Dispatcher magic</a></li>
  </ul>
  
  <p>and I'm sure there is more.</p>
  
  <p>The cool build kit tools seem based on the <a href="http://api.symfony.com/3.1/Symfony/Component/Console.html">console component</a> too.</p>
  
  <p>So the question is:</p>
  
  <p><code>How much symphony magic, and which bits, are worth understanding?
  </code></p>
  
  <p>If that question is too open: <code>Are there bits that have been rejected for another approach?</code></p>
  
Tags: <php><coding-standards>
Title: How much symfony do I need to learn if I am going to be a CiviCRM core hacker?
ThreadText: # How much symfony do I need to learn if I am going to be a CiviCRM core hacker?
  
  (Asked by: username_0 on 2017-01-31)
  
  I'm bit of a CiviCRM noob, but I'd like to help out and fit with the current patterns. I keep encountering bits of [Symfony](http://symfony.com/) in core code and it seems well respected... and pretty cool.
  
  So far I have identified these in the core:
  
  * [Dependency Injection containers](http://api.symfony.com/3.1/Symfony/Component/DependencyInjection.html)
  * [Event Dispatcher magic](http://api.symfony.com/3.1/Symfony/Component/EventDispatcher.html)
  
  and I'm sure there is more.
  
  The cool build kit tools seem based on the [console component](http://api.symfony.com/3.1/Symfony/Component/Console.html) too.
  
  So the question is:
  
  `How much symphony magic, and which bits, are worth understanding?`
  
  If that question is too open: `Are there bits that have been rejected for another approach?`
  
  **Tags:** php, coding-standards
  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_2 on 2017-02-01. Score: 6 | Accepted answer
  
  Those are the three that we use now, although I'd usually prefer to read the guides rather than the autogenerated API docs, i.e.
  
  * [Symfony Service Container](http://symfony.com/doc/2.7/service_container.html)
  * [Symfony Event Dispatcher](http://symfony.com/doc/2.7/components/event_dispatcher.html)
  * [Symfony Console](http://symfony.com/doc/2.7/console.html)
  
  This blog from `civicrm.org` is probably relevant: [The static is dead. Long live the static!](https://civicrm.org/blog/totten/the-static-is-dead-long-live-the-static)
  
  To date, most of the Symfony usage has been internal -- e.g. `Civi\Core\Container` originally followed a... radically minimalist approach (verging on antipattern) by putting all the service definitions in one PHP file. But it's starting to open up a bit for downstream dev:
  
  * v4.7 introduced `hook_civicrm_container`
  * `cv` recently added subcommands for `debug:container` and `debug:event-dispatcher`
  
  However, I don't regard it as consumer-friendly right now because all service-definitions and event-listeners are declared in PHP code. I'd really prefer (a) bindings for YAML/JSON/XML files and (b) some kind of autowiring for the dependency injection.
  
  
  ---
  
  ### Answer by username_1 on 2017-01-31. Score: 9
  
  You must be digging pretty deep if you're running into Symfony. Its introduction into the stack is fairly new. CiviCRM has been around for over ten years, so some of the technologies are pretty hip and new (like Symfony) and some of the technologies, like Smarty or PEAR DB... well, not so much.
  
  I think I've run into Symfony in some code around events (like... programming events, not CiviEvents) and maybe in some of the new command line tools. If your primary concern is fixing bugs, you may never even see it, as many of the bugs tend to live in older code.
  
  Bottom line: It's a technology the core team would like to adopt, but adoption is happening slowly. I wouldn't say that Symfony experience is a prerequisite for developing CiviCRM any more than AngularJS experience is.
  
  > **Comments:**
  > **username_0**: I like it deep @GinkoFJG  
  
  ---
  
  