TAG | LooseCoupling
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.
When my team laid their hands on the plugin they almost instantly found some nicely hidden bugs so I had to get busy again which proved a quite intense experience.
In the end result the plugin also gained an option to dramatically reduce the number of queries in the admin modules of your composition-able models.
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!
For a while i am now working on a plugin to allow easy page composition. I wrote about the basic idea previously.
gjPositionsPlugin has seen quite some change since as it turned into a doctrine behaviour and symfony admin theme combination. Now the main thing left is some jQuery action to add usability.
Unfortunately the current structure does not allow easy collaboration as the plugin only defines functionalities that can be incorporated by your application. It does not work standalone. That’s why I had the idea of another plugin for demonstration purposes only. (more…)
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.
My employer is a big magazine publishing house and in the three years working there I had the opportunity to work on or just follow the development of more than 20 editorial websites. These included very different types of sites; some community driven, some purely editorial, some service providing and more.
There have been many differen requirements but most of the time the requested features were reoccuring in similar ways.
One of most frequently requested feature was to provide an admin tool to compose homepage (a.k.a. indexpages, sectionhomes, channels,..). An editor should be able to compose the layout of a homepage by positioning design elements like top teasers, slideshows, two column boxes, three column boxes and so forth and furthermore he should be able to manually assign contents to those elements. These contents of course can be of various types like article, galleries, doissiers, quizzes, etc..
This is my approach to solve this requirement once and for all!
But what if there is no real relation but only one by convention? What about loosly coupled data that is not referenced by a foreign key but by two fields containing the model and the primary key? What is easy enough to understand for a human machines should be able to manage too.