Slightly OT, but admin_menu module is using two approaches that could be interesting for this discussion:
-----Ursprüngliche Nachricht----- Von: development-bounces@drupal.org [mailto:development-bounces@drupal.org] Im Auftrag von Greg Knaddison Gesendet: Mittwoch, 2. Januar 2008 12:13
On Jan 2, 2008 12:59 AM, Khalid Baheyeldin <kb@2bits.com> wrote:
On Jan 1, 2008 6:49 PM, Gerhard Killesreiter <gerhard@killesreiter.de>
Also, admin/settings/MYMODULE is the most obvious place to find settings for MYMODULE.
For this specific case I think you are right, but we also have a real problem of "too many menu entries and pages" in the admin/ area. People look at that jumble and (still) get overwhelmed. Re-using existing forms reduces that problem.
Especially on full-blown Drupal community sites, the list of settings pages becomes so big that it no longer fits on smaller screens. The proposed solution (http://drupal.org/node/196772) is to group all settings pages below admin/settings after the module 'package' information in .info files and move all Drupal default system settings into a new sub-group 'System'. AFAIK, the package info is currently used on the admin/build/modules page only. While I'm not happy with the categorization there (often finding myself searching through all collapsible fieldsets for a certain module to enable/disable), it makes sense to re-use the same categorization for other purposes like the admin/* and admin/settings screens. Two benefits: Module settings are comprehensible categorized, and module maintainers are encouraged to add meaningful package information to their .info files (which is not always the case).
For some more concrete evidence - I have never seen an issue for a module that uses admin/settings/MODULE that said "I just installed your module and can't find the settings page." I _have_ seen issues where core forms are form_altered that say "I can't find the module settings - this module is broken" (e.g. http://drupal.org/node/198015 )
We are choosing between the lesser of two evils (busy admin area, easy to find/control settings).
As of now, admin_menu does not provide regular module settings. However, there are some variables for development to make the output of admin_menu more verbose. Providing those variable settings on an own settings page didn't make sense from a usability view of regular users. Thus, admin_menu allows to configure these variables on the settings page of Devel module. This adds another benefit (quoting from the corresponding Devel issue http://drupal.org/node/126646): "I my opinion, any development related settings should be kept together at a central place. Just think of a Drupal site you are developing/releasing for a client - I assume that you do not want to give your client the chance to enable or alter any development settings. To circumvent this, a reasonable solution is to provide all developer settings in the Devel module, because access to devel can be permitted separately from access to any other module - without introducing a new developer access permission for each and every module. In case of Administration Menu it's even more reasonable: It does not have a settings page yet. And AFAIK, it is not the only one." Regards, Daniel