Author Topic: brainstorming past Doctrine (Read 754 times)

JoeMurray · December 02, 2013, 08:52:09 pm

In a very big move, CiviCRM will focus 4.5 on replacing lots its DB layer with Doctrine. Doctrine has a big community behind it, plays nicely with Symfony, is partially adopted into Drupal 8, with more possibly on the way.

Our large packages diectory shows that CiviCRM does not suffer from the Not Invented Here syndrome. As we move to refactor our code and modernize our software infrastructure, we should look not only at our pain points like the DB layer and the form / templating layer, but for areas of opportunities. In the interests of sparking a discussion about possible important technology moves, I'm going to throw out some thoughts on what we could / should do.

Here is a nice recent review of parts of Symfony that are going into Drupal 8 http://crossfunctional.net/blog/2013/mar/symfony-components-in-drupal-8

Given the direction of the web and especially the need for a CRM to interoperate with lots of other systems, I wonder if HttpFoundation and HttpKernel and Guzzle might be helpful to us.

As we move to having more extensions covering and extending overlapping areas of functionality, we might benefit from DependencyInjection.

Twig seems promising as a presentation layer technology:
http://upstatement.com/blog/2013/10/comparing-php-template-languages-for-wordpresss/ I believe that CiviVolunteer used two or three Symfony components for its UX work.

As we ponder how to get business logic out of forms and into our BAO layer underneath API calls, it might be a good idea to consider doing the easy validation stuff using Validator and Doctrine Annotations.

One area where CiviCRM is criticized for being overly complex and hard to use is configuration. I haven't reviewed the YAML component but I do think D8 has some good stuff going on in configuration management based on top of it.

CiviCRM pages tend to be heavy in terms of kb downloaded. Regarding the bulk of the content going over the wire, Assetic might be useful if can play nicely with all three CMSes.

Reactions? Other thoughts?

jaapjansma · December 03, 2013, 06:26:11 am

As an experienced Symfony developer I would say that creating the entities from civicrm in a doctrine way is quite easy (read automated). Doctrine comes with some console tools which could generate an Entity and an Entity Repository (the database query class) from the database structure.

That means that we get the basic stuff into an entity and completly object oriented... Custom (complex) queries which I think are in the DAO should be rewritten into DQL into the entity repository class.

JoeMurray · December 03, 2013, 07:21:30 am

Yes, I agree. I believe this work is currently underway for CiviCRM 4.5. I imagine it involves rewriting https://github.com/civicrm/civicrm-core/blob/master/xml/GenCode.php and the templates used to generate DAO files.

Any thoughts on what other Symfony components we should look at in addition to Doctrine?

totten · December 03, 2013, 08:54:17 am

For me, the top candidates would be:

* Dependency Injection -- When you have DI, it changes (improves) the way you design classes. There's a lot of code in Civi that uses PHP's "class" construct but which isn't really good OOP -- code which becomes hard to test and refactor because it's hard to grok the dependencies when everything is a static function call.

* Composer -- We have two similar issues regarding download of packages. Firstly, we have civicrm-packages.git and Civi's internal dependencies -- our practices around forking dependencies have been a bit muddied, and our practices lead to some very big downloads (eg the .git includes 3 copies of the 32mb selenium.jar -- ~100mb download for developers -- and we can expect that to grow by 32mb every couple months). Secondly, we have extensions and their dependencies -- as we produce more of these, we'll find more extensions depending on each other and on external libraries. Improving this will make it easier to share code / collaborate / experiment.

* JS-MVC -- This isn't really something in Symfony, and (to some extent) it competes with Twig/Symfony Forms. By adopting a client-side framework like Backbone, Angular, or Ember, we can produce a smoother and more intuitive backend UI. (I focus on the backend UI because I think the requirements for the backend and frontend are pretty different.)

* Test Structure -- Our test suite includes simple tests and complex tests; PHP unit-tests, JS unit-tests, and full-stack integration tests; core tests and extension tests. As extensions become more important, they'll raise more issues with testing. And we already have challenges with slow/inconsistent results in the full-stack integration tests. Our test suite has grown in recent years, and our test architecture should grow with it.

JoeMurray · December 03, 2013, 11:01:49 am

+1 x 4.

CiviCRM Community Forums (archive)

News:

Author Topic: brainstorming past Doctrine (Read 754 times)

JoeMurray

brainstorming past Doctrine

jaapjansma

Re: brainstorming past Doctrine

JoeMurray

Re: brainstorming past Doctrine

totten

Re: brainstorming past Doctrine

JoeMurray

Re: brainstorming past Doctrine