Posted by PatchRanger on
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
- #1798878: Add Timegate method in oop-style
- #1805214: Create RecipebookUI
- #1815084: Create FormUI
- #1805152: Move Honeypot recipe to OOP-architecture
- #1805154: Move Honeypot2 recipe to OOP-architecture
- #1805158: Move NoResubmit recipe to OOP-architecture
- #1805160: Move ObscureUrl recipe to OOP-architecture
- #1821470: Port admin links functionality to OOP
- #1826782: Code cleanup after refactoring
- #1827000: Restructure the module to turn into MVC-application
- #1827044: Release a stable D7 version as a result of OOP-refactoring
- #1827046: Migrate D6 to OOP-architecture
- #1833214: Release a stable D6 version as a result of OOP-refactoring
Comments
Comment #1
PatchRanger CreditAttribution: PatchRanger commentedComment #1.0
PatchRanger CreditAttribution: PatchRanger commentedClarify.
Comment #1.1
PatchRanger CreditAttribution: PatchRanger commentedEnhance Roadmap.
Comment #1.2
PatchRanger CreditAttribution: PatchRanger commentedAdd one more point to Roadmap
Comment #2
dddave CreditAttribution: 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 CreditAttribution: 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 CreditAttribution: PatchRanger commentedAdded UI major tasks.
Comment #3.1
PatchRanger CreditAttribution: PatchRanger commentedAdded admin links issue.
Comment #3.2
PatchRanger CreditAttribution: PatchRanger commentedRoadmap updated
Comment #3.3
PatchRanger CreditAttribution: PatchRanger commentedAdded the last (I hope) point
Comment #3.4
PatchRanger CreditAttribution: PatchRanger commentedRoadmap extended with releasing a stable version and porting this functionality to D6
Comment #4
PatchRanger CreditAttribution: 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) CreditAttribution: commentedAdded release issue for D6