| Project: | Accessible Helper Module |
| Version: | 7.x-2.x-dev |
| Component: | Code |
| Category: | support request |
| Priority: | normal |
| Assigned: | erynn |
| Status: | active |
Issue Summary
I may be on the wrong track with this so correct me if I am misunderstanding something.
I was looking at starting a fix for enhancing the autocomplete feature., http://drupal.org/node/1195412 with help from this patch - http://drupal.org/files/issues/autocomplete_3_1.patch. I am confused as to how this module will structure fixes. The patch contains some useful fixes that use 2 or 3 different core modules. How would I go about doing this? Would I make three different module.inc fixes that each do something to enhance autocomplete. I already have user.inc for the password checker; Should I put code for a different fix in the same file? How would I go about making this fix a selectable option (where would I put it?) as autocomplete.js is used in the form.inc in /includes/ and it is not module specific.
Also this may be a problem down the road if we have a fix that requires 2 or more modules.
This is from my understanding that, the Accessible Module checks to see if module x is enabled, and then enables its fix x.inc. If I have a fix that requires module m and module n, and only one is enabled, my fix would end up breaking as its missing some components. But, if we made it so that the fix could still have some functionality with only one of the modules enabled, how do we control which admin.inc file should have all the admin stuff?
Comments
#1
I would suggest a subfolder in accessible_fix named af_autocomplete with a module named af_autocomplete.module in it. And a complete module for this.
It can get pretty complicated. I've gone back and forth on how to structure accessible fix. The important thing with contrib fixes is to be able to turn them off when they are fixed. With core, the fixes are much less likely to be committed.
Any mix of the following seem reasonable:
- make each fix its own module. this resolves all the issues you mentioned above and makes coding much easier. Patches look much more like drupal patches than funky accessible helper patches. I think this is definately the way to go for patches involving more than 1 module.
- the current structure. Maybe useful for performance and keeping code base smaller. But every new drupal hook that needs to be implemented means it needs to be implemented in accessible fix module. I'm not sure if this structure is working out.
Either approach can have as unified of user interface as we like.
#2
Maybe keep both structures but have them focused on two different types of fixes, which is what I think we are going to end up having. Module Specific: i.e block, filter, wysiwyg, color. Then a feature specific: autocomplete, login etc. That way, it would be easy for someone to make a fix for a very specific issue, even if a module that is involved in that issue has a general fix already. You wouldn't have to go hacking around the module specific code and raise the chance of breaking something. It would keep everything separate and it would be easy to add and drop code as we need too.
#3
+1
#4
Here is a patch for the structure I suggested. If you don't have a problem with it, I will commit it.
#5
looks fine to me.