Hello Everyone,

I've been thinking about this for a little while now and I'd like to solicit feedback regarding placing logic in the:

  • {module}.module
  • {module}.admin.inc

To check whether a module-specific persistent setting is either TRUE or FALSE with respect to applying some dimension of module logic.  

The intent is to enable the module to disable or enable bits of itself within its own configuration area as opposed to having to do that at a somewhat more macro level in the platform-level Functionality area.

One way to think about this is installing a light switch in a room to control a lamp outlet as opposed to turning off the lamp (and entire room with it) by flipping a breaker in the distribution panel.

Am I missing something?  

If this is already being done, how is it being done?  I'd like to follow best practices.

The alternative is a proliferation of small, single-purpose modules.  I have no objection to that, but the pattern I see when it comes to modules is that some are single-purpose, but many are not.

How is fine-grained enable/disable functionality of complex modules best achieved?

To further clarify, I am not talking about how to capture settings in a persistent way.  I just wrote a small monograph about that very topic to help straighten out my thinking.  

What I am asking about is emerging policy regarding how to go about enabling/disable the application of functionality of a multi-functional module on a discretionary basis.  I am wondering what people think about:

  • Where that should happen
  • How that should happen
  • Existing design patterns that have achieved this goal

I don't want to waste time re-inventing the wheel, and I'd rather follow (and leverage) the brainpower of those who have come before me.

g.
----

Comments

For me, while I do find it a little tedious to try and search on the module page or scroll down a long list...

I do know where the functionality is, so I don't have to try and find the settings in a multitude of places.

Hope this helps.

I think a use case would be helpful in me understanding your question. 

Of the top of my head, it sounds like what you are looking for are module-specific settings. Each module can "own" one or more sets of configuration, which are installed alongside the module when it is installed, and removed with the module.