-
Notifications
You must be signed in to change notification settings - Fork 1
/
README.refactoring
59 lines (40 loc) · 1.96 KB
/
README.refactoring
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
Even More Refactoring Ideas, DTM 4 June 2011
============================================
Ya know, doing OO inside of Drupal just wasn't such a hot idea either.
Drupal's module system can be used to split apart functionality just fine.
Nor was creating a separate menu entry for every single menu item, when
a "router" function would have worked just fine. Oh well.
First, I should probably split out some of the code from reg.module into:
includes/ - (directory for holding includes from main reg module)
Then I should move code from existing core classes into into these Drupal modules:
reg_email: reg_email()
reg_message: reg_message_load()
reg_form_success
reg_form_verify
reg_form
reg_captcha - (maybe I can replace this with the latest CATPCHA module?)
reg_onsite: reg_onsite_main(), reg_onsite_form()
reg_validate: reg_validate_main(), reg_validate_form()
reg_util - Unsed badge numbers and duplicate membership search
reg_util_print - Badge printing
reg_admin - Main admin module
reg_cancel - Admin screen
reg_level - Admin screen with functions for main form
reg_member - Admin screen
reg_search - Admin screen
reg_settings - Admin screen
reg_stats - Admin screen
...now, will I ever actually write all of this? Right now, the registration
system is mature, and it WORKS. I don't think it's such a hot idea to
rewrite a bunch of existing code that works just to "make it more modular".
Changes are greater than not that I won't ever do a rewrite of this
magnitude, but time will tell.
Refactoring Ideas, DTM 5 Apr 2009
=================================
In hindsight, mixing inheritance with a factory class really wasn't such a
good idea.
As development progresses (and as I write more unit tests), I should see
about cutting down on inheritance and use dependency injection instead.
I might want to switch to camelCase function names at some point, too. I'm
going to use them for unit tests right now, and maybe I'll do the same
in the main classes in the future.