Op woensdag 2 februari 2005 12:13, schreef Andre Molnar:
> Bèr Kessels wrote:
> > Could be please leverage these discrussions to a higer level?
>
> I read the wiki pages. My 0.02.
>
> The real solution is to allow each module to build its own menu/s.
Not
> as local tasks - but full on stand alone menus that get blocked.
This
> guarantees that each menu will automatically have all like items
grouped
> together - and all settings are handled in the right place.
>
> user_module should only handle building user menu blocks - right now
it
> is in charge of blocking not only user menu items and user setting
menu
> items - but all module settings menu items as well. Not the place
for
> it IMHO.
Right. But the *allow* part should be stressed. It is not *must*.
Because, for
example, xtrastatistics.module should not make a menu block extra
statistics,
but should place its menu entries under statistics.
In actuality the extension of a module in
that manner should not happen. This is against the whole concept of
plugin modularity. Probably the reason for the prolification of modules
is that they are not autonomous as they should be. Many of the present
modules should be completed as variants of the original an thus be able
to relplace them entirely.
If a module is dependant on another module for UI controls then that
module should be able to replace the original entirely. In this case
statistics.module would not be used or installed but
xtrastatistics.module would replace it and carry with it all
statistics functionality and the newer functions along with the
necessary UI.
This philosofy is one that is solid in other software industries but
only in parts of Drupal. Holding to it in the case of modules would
solve a lot of the problems with UI and and database modification.
--
Untitled Document
Carl McDade