Refactoring the module hierarchy and naming conventions

I agree that the naming convention should be decisions_hook_name(), where "hook" is the module name, as I think this is the convention all around drupal. It also makes the functions sortable properly. :)

As for having modes as module, I think it's a pretty good idea, because it will allow admins to easily turn on and off decision modes system-wide, and will make the uninstall hook a bit cleaner.

I think that the modules should be named decisions_. That might sound trivial, but it's actually very interesting because it allows us to use the classic Drupal hook/module system to call the functions of the submodules, see http://api.drupal.org/api/HEAD/function/module_implements

Note that I just committed a change that fixes the submit() hook to conform to that convention, but there's a lot more to do...

the decisions_votingapi_calculate() hook could probably go away when the modes take care of this themselves.

This is a really good idea! I always felt that the mode implemantation was a bit "hackish", and by using already proven ways of extending a module we can hopefully benefit from previous work done in this area.

I've overhauled the naming of the different functions. I've also started experimenting with making the ranking mode a module, it works pretty well. I only needed to add a hook_help() and the attached .info file (and of course rename the .inc to a .module). Now, of course, I need to setup hooks properly.

I will continue testing another day, but it is becoming clear that the naming convention already needs to be redone because decisions hooks should start with "decisions_" and therefore the modules functions should be named mode_decisions_hook()...

A question from a user perspective: With the use of modules, will it mean that the user will have to enable more that one module to achive basic functionality? Or will the Decisions module still have the basic functionality and then if the user wants additional functionality they can enable "sub-modules"?

Well, right now it's gearing up towards a scenario where decisions would come with no decision mode activated (since they would be additionnal modules), which is probably a bad thing. However, I think it's a still very interesting feature because it allows the site admin to deactive decision modes globally. Same would go for quorum, end dates, electoral lists... ideally, that is.

The only problem I see with that approach is that the module wouldn't be functional without an activated module.. Maybe there should/could be a default decision mode that is always active... Or maybe that decisions could activate a "random" mode when being installed, but I'm not sure that's possible...

Just thinking aloud....

I chatted a bit with webchick, and we came to the agreement that it would be fairly easy to activate (say) the decisions' poll.module (which will have to be renamed to something else) when decisions is installed. This way there is at least one decision mode available.

The keys to doing that are hook_install and module_enable.

What is still an issue though, is what to do with existing nodes that have their decision mode disabled... A corner case, but a problem nevertheless. I think those should just feature a warning pointing to the modules list for reactivation. :)

Ok, I messed up. The module name is "ranking", so the hooks should be called "ranking_decisions_hooks". Poll needs to be renamed so not to conflict with the originale poll.module.

A simple way would to have the modes named "_mode" (like "ranking_mode"). Therefore the function names would be "ranking_mode_decisions_hook()". On the other hand, that makes for a pretty long name. "ranking" should be unique enough, we have a problem with "poll". I think "selection" is a more appropriate name, and i'll go forward and rename the files, functions and modules for that.

enter selection.module and ranking.module! :)

I have made the move, and decisions modes are now modules (#46584). I have also renamed the hooks following the new convention (#46585). We don't profit from the modularisation completely yet: we don't use module_invoke, but that's impossible for some hooks that are explicitely called, based on mode. E.g. we don't want to call ranking_view_results() on polls. But for some hooks, it is appropriate (e.g. _algorithms).

I'm sorry I didn't comment on this earlier, but I didn't realise you were naming them "ranking.module" and "selection.module". But shouldn't it be "decisions_ranking.module" as e.g. Views does it? Doesn't this have a high potential for naming collisions with other Drupal modules?

I thought about this... views does it, cck doesn't, ecommerce doesn't... i think it varies.

right now, i think the names are unique enough not to cause conflict. In other words, "we'll cross that bridge when we get there": if/when there's a conflict, we can simply rename the module... it's easy enough:

* rename all the functions
* rename the files
* change the .info

The problem with "decisions_ranking" is that function names get insanely long and ugly. Since hooks are prefixed with "decisions", you get silly names like "decisions_ranking_decisions_view_results", a whopping 40 characters...

But you have a good point, which I should have explicitely documented... The move isn't finished yet either.. :)

Note that some work will be performed on this as part of the Drupal 6 port: http://drupal.org/node/339242

See #532758: 2.0 - refactor algorithms into modules for now.