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.
Hello @herb,
I think your way of describing it is quite elegant.
Speaking for myself, I find rooting around for settings to be quite the drag.
A nice feature of the /admin/modules area is the "Configure" link, which (when used) makes for easier wayfinding to the actual functionality of the module in question:
To my mind, clicking on "Configure" should lead to a place where all of the toggle switches and input fields that control the global behavior of the module reside, along with everything else that helps to orient the Administrator as to what that module is, why it might be deployed, how it works, how to get additional help and so forth.
As for a use case, here's a couple of VERY PRELIMINARY screenshots of a "toy" module I am developing (mostly to help get my programming skills up) that might help to better illustrate what I am driving at:
and:
To ultimately get:
People, please don't jump all over me for showcasing a D7 application here.
Once I get this module working in my D7 instance, I plan to port it over to BCMS.
I need a fully functional i18n and Ubercart environment to be available to me in BCMS before I can contemplate shifting my production environment over. Many of the modules and functionality I rely on in D7 haven't been ported yet, so I am stuck in D7-land for the next little while.
Any feedback welcome.
g.
----