CHOONG
Webdevelopment
cwtDoctrineActAsLikablePlugin, part 2: Analyzing the functionality
Jul 18th
This is a series of blogposts about writing the plugin itself. For instructions on downloading, installation and usage, please refer to the cwtDoctrineActAsLikablePlugin project page.
Table of contents
- Part 1: Why I am building this plugin
- Part 2: Analyzing the functionality
- Part 3: Investigating how to write the actual code
- Part 4: Writing the actual code
- Part 5: Testing the plugin
- Part 6: Writing documentation
- Part 7: Releasing the source code
Part 2: Analyzing the functionality
Quite some years ago now, I started playing around with PHP. As I was not studying Computer Science, I wasn’t taught to think things through before starting to write code. This resulted in me writing lots of code which even I myself had a hard time maintaining. Years later, experience has taught me exactly this. So before I start programming, I’ll first describe the requirements of this plugin.
For my own project, I just want people to be able to ‘like’ and ‘dislike’ posts. But as I’m releasing a plugin, this needs to be made more dynamic. For example, other users may want this functionality to apply to comments, photos, videos, etc. To facilitate this, we’ll be building a Doctrine Behaviour.
Do we want only logged in users to be able to use the functionality, or should it be available to anonymous visitors as well? This should be configurable over the app.yml.
In order to relate likes/dislikes to specific users, we need to have users in the first place. Since there is already a great plugin available for this kind of functionality, called sfDoctrineGuardPlugin, we will be using it.
When a related object is deleted, any corresponding likes/dislikes should be deleted as well.
As this plugin will be available to the Open Source community, we need to make sure the code is well documented. We will be doing the low-level documentation using phpDocumentor. Installation instructions and recipes will be made available on a project page.
For the same reason as above, we need to ensure the quality of the code, and make sure nothing breaks when we refactor or add new features. We will be using phpUnit to write unit tests in order to achieve this.
cwtDoctrineActAsLikablePlugin, part 1: Why I am building this plugin
Jul 18th
This is a series of blogposts about writing the plugin itself. For instructions on downloading, installation and usage, please refer to the cwtDoctrineActAsLikablePlugin project page.
Table of contents
- Part 1: Why I am building this plugin
- Part 2: Analyzing the functionality
- Part 3: Investigating how to write the actual code
- Part 4: Writing the actual code
- Part 5: Testing the plugin
- Part 6: Writing documentation
- Part 7: Releasing the source code
Part 1: Why I am building this plugin
At the moment I’m writing a little application in Symfony which requires rating in a Like/Dislike kind of way. Ever since reading this post, I’ve come to much prefer this kind of rating system over the old ’5 star’-system. A search for existing rating-plugins quickly turned up sfDoctrineActAsRattablePlugin (no, that’s not a typo on my side). However, there are several reasons why I don’t want to use this plugin:
- It’s built around the idea of a ’5 star’-system
- The link to the author’s wiki on this plugin is dead, which I consider to be a bad sign
- It’s been almost a full year since anything happened on the project’s SVN
So I decided to write my own plugin. The only problem here is that I’m a PHP developer with limited experience in producing code for the Open Source community, and I’m not into unit testing at all. But writing my own plugin is a great chance to get some practice in these fields, while also (hopefully) contributing something useful to the community.
If you’re like me, you might feel a little afraid to Open Source your code. Am I actually skilled enough to contribute something useful? Will people laugh at my code? Will I discredit myself if I release this? For someone who has limited programming experience and no Computer Science background, I think these are valid questions. However, I also think that by keeping in mind that your code is going to be open to the public, you will be writing better code by default. Plus you will learn a lot by getting feedback from the community.
This series is meant primarily as a way for me to structure my thoughts while writing this plugin, but I hope it may also inspire other developers like myself to Open Source their code.
Comments