Closed (fixed)
Project:
BOTCHA Spam Prevention
Version:
7.x-2.x-dev
Component:
Code
Priority:
Major
Category:
Task
Assigned:
Reporter:
Created:
5 Oct 2012 at 17:29 UTC
Updated:
4 Dec 2012 at 11:20 UTC
Motivation
It becomes rather hard to maintain this powerful module because of non-trivial logic it provides.
It needs some love indeed.
I mean we should do some refactoring to make its code more easy-to-read.
Switching to object-oriented architecture would be nice in my view.
Please note: everything is going to be ported to D6 after completion of full migration for D7, because to that moment we will have (I hope) a really MVC-application which can be easily ported to D6 just by changing model layer.
Roadmap
Comments
Comment #1
PatchRanger commentedComment #1.0
PatchRanger commentedClarify.
Comment #1.1
PatchRanger commentedEnhance Roadmap.
Comment #1.2
PatchRanger commentedAdd one more point to Roadmap
Comment #2
dddave commentedI am not a coder but a very happy user of this module which currently works great. I appreciate that you as a maintainer are going to put some serious efforts into this.
My question is: This migration seems to be non-trivial. Shouldn't this be done in a separate branch (7.x-2.x)?
I guess you wouldn't advise "normal" user to upgrade to the latest dev. So perhaps a little word of caution that the dev is currently in fact under heavy development might be in order.
Comment #3
PatchRanger commentedThank you for your feedback, David. I am glad that my work is noticed by the real person - not just by spam bots we are fighting with:)
You are totally right that it should be done in a separate branch. When I've started to work on this migration, it doesn't seem to be so huge. But now when I see the real size of it, I don't think it makes sense to switch branch during the development. You don't have reasons to worry: every change is covered by tests and 2 versions of the same program currently co-exist in the code of BOTCHA. They are switched by setting a variable botcha_oo_migrate to 1, which is by default unset - so the latest dev looks like (and works like) as a stable release. When the migration becomes completed, I will just switch the main logic of the program from one rails to other and remove old way. Since everything is covered by tests, it is going to be painless operation.
You are right, it should be in place.
Done: https://drupal.org/node/1509114.
Comment #3.0
PatchRanger commentedAdded UI major tasks.
Comment #3.1
PatchRanger commentedAdded admin links issue.
Comment #3.2
PatchRanger commentedRoadmap updated
Comment #3.3
PatchRanger commentedAdded the last (I hope) point
Comment #3.4
PatchRanger commentedRoadmap extended with releasing a stable version and porting this functionality to D6
Comment #4
PatchRanger commentedThe refactoring finally got its own branch, the 2nd for both Drupal versions (I mean 6.x-2.x and 7.x-2.x). Stable releases are available.
The plan is done, hoorah! Thanks for all who contributed.
Comment #5.0
(not verified) commentedAdded release issue for D6