On Sunday 22 January 2006 11:28, Khalid B wrote:
Has anybody talked about using "functional" folders?
If you mean on the admin/modules and admin/settings pages, then yes, this is something I thought of. If we have "system" or "drupal", then groups that are categoriezed (much like RPMs on Red Hat for example: Internet, Games, Development, Office, ...etc.)
So, if we have drupal, community features, ecommerce, admin tools, misc, ...etc.
Again, this can be a settings in the modulename.ini file
category = 'Site tools'
The trick is what hierarchy we put in place, and agreeing on such a basic hierarchy.
If you mean we group the directories to be like that, then I disagree. Modules already have a place under sites/default/modules, sites/sitehostname/modules or (if we implement it) sites/all/modules, each in its own directory. Things that depend on other modules (e.g. ecommerce contrib) can be under their main module.
Just an FYI, the sites/all suggestion from an earlier thread is already slated for inclusion early in 4.8. http://drupal.org/node/44920 That is step one of fully separating core and admin-added plugins. Step 2 would be the drupal/ or core/ or whatever directory that some have discussed. Since that requires a lot of moving stuff around in CVS, I think that really has to be done by Dries. That would also be the proper time to move all core modules into their own directories, which I agree is what we should be doing. That would then allow us to do a lot of other breakup and refactoring that needs to be done, for various reasons. I'm liking this ini file idea to replace/supplement hook_help(). You only need a little bit of metadata for admin/modules, not any of the functionality of the modules in question. Name, dependency information, description, etc. can all be put in there and parsed in a split second, even if they're then just put straight into the system table and pulled from there thereafter. Currently, as far as I am aware the system will parse any module file anywhere in the modules/ directory (and its kin). The file structure of the directory should reflect the packaging, not the dependencies. If a given tarball comes with modules modA, modB, and modC (like ecommerce), they should all be in the modules/mod/ directory. If another module, modD, is an extension to modB, it should say so in its metadata, not its file location. Consider that mod/ may be in sites/all, but you only want modD available on the sites/myexample.com/ site. You can't do that if it's filesystem dependent. So +1 to an ini file. +1 to every module having its own directory. Assume sites/all/ will happen, since Dries seems to like it as well. :-) -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson