TAG | Behaviours
Well for example if it contains records that don’t really belong there. So you iterate over them and throw them out, right?
Only halfway there because doctrine collections have a memory and have secretly taken snapshots!
Sometimes you might be tired to use the same behaviour on all your models with all the same options littering your schema.yml.
This is where I started and this is what I found.
If you ever wanted to limit your left joins not only by matching keys but with another condition, this will probably help you.
Today I am happy to announce that this plugin is now available in its first beta version!
Not only I managed to implement the basic idea of composing design and content elements on a canvas; by now the plugin became completely independent from your models and database structure!
When you loosely couple your doctrine models with the doctrine behaviour LooseCoupling there is a chance that on the active side (the one holding the relation information) you will get a lot of orphaned entries over the times for each deleted item on the passive side.
Well, this is no longer the case now.
Many of you will have played around with Doctrine behaviours before. I certainly did and one of my latest experiments is the LooseCoupling behaviour that allows you to work with loose relations without leading to high amounts of database queries.
Today I found a bug in this behaviour that was the result of my apparent misunderstanding.
Recently I wrote about extending Doctrine_Query to define convenient methods with speaking names that wrap query parts that you use quite often.
I got criticised for defining methods there that did not return a Doctrine_Query instance but an actual result set. And while I was buying the argumentation I could not change it as my Query class belonged to a Doctrine behaviour and therefore I didn’t have control about the table in question.
Only then I learned by another commenter about delegate methods for tables.
Today I want to give a brief overview on the possible ways how to achieve this within symfony/doctrine (1.4/1.2) projects.
I just recently wrote a Doctrine behaviour which formed the base of a symfony plugin. The behaviour provided a defined list of columns to the models and the plugin performed some operations based on these columns.
Now with behaviours you can easily write delegate methods which you can define on the record template but call directly on the model. But what if you need some methods on the models table class that you can call from your plugin code?
Decoupling classes is all the rage right now and for a good reason as it helps you separating your concerns putting a concerns code in one dedicated place and reducing the risk of ripple effects.
However in theory it often seems very abstract and might not be that intuitive. So today I will introduce how you can use Doctrine behaviours to achieve decoupling of functionalities.