[development] Modules page rework

[Earl Miles]

Moshe Weitzman wrote:
> looks like a big improvement to me. if you are into experimenting, i 
> would try this out with just a table and no fieldsets. use subtabs for 
> things like 'contrib', 'installed'. the default should show lots of 
> modules i would think, like today.

My very first experiment used the javascript tabs, and I believe I am 
leaning toward going back to using normal tabs for that, but there's a 
lot of ideas coming at me and putting them all together could be tricky.

1) module status -- I hadn't gotten to that part yet, but there's a lot 
of potential for Great Good here by including a hook to let modules say 
if critical things need to be done. Also, it'd be an ideal place to 
record that update.php needs to be run for modules.

2) Hide required modules. I'm getting mixed response to this so far, 
there is some interest in retaining this data, some interest in hiding 
it. I'm on the fence at this time.

3) Reducing the lists to, perhaps, 'enabled modules', 'disabled modules' 
(note that I intend to have two actual status' there: disabled and 
uninstalled; disabled is not on but might have data (schema) in the 
system still, uninstalled does not have data in the system). Disabled 
modules, then, won't include the enabled modules at all. A 3rd table 
could list the required modules, which'd basically be there for 
information purposes. But then, removing them from the enabled modules 
list might be problematic as well.

4) Displaying said tables more like this:

required modules
   node        field          field        etc
   user         etc
   ...
drupal core
   aggregator  ...
   archive ...
   blog ...
   ...
contrib
   devel ...
   views ...
   ...
ecommerce
   product ...
   store ...
   ...

All in the same table. Of course, if package is just a field, we could 
implement click-sorting and the user could alphabetize the modules or 
sort them by package. Maybe we could even sort by status or some such.