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-bouncesdrupal.org] Im Auftrag von
Greg Knaddison
> Gesendet: Mittwoch, 2. Januar 2008 12:13
>
> On Jan 2, 2008 12:59 AM, Khalid Baheyeldin <kb2bits.com> wrote:
> > On Jan 1, 2008 6:49 PM, Gerhard Killesreiter
> <gerhardkillesreiter.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
|
