On Friday 06 January 2006 06:19 pm, Larry Garfield wrote:
OK, I think I started thinking aloud there. :-) To recap, I'm suggesting every module be required to be a directory in /modules (or wherever), and have magic-name files for resources as well as code. So any module consists of:
/mymodule /mymodule.module (required) /mymodule.css (optional) /mymodule.js (optional)
Then the admin/modules page gets 2 extra columns of checkboxes: Use Module CSS and Use Module JS, both of which default to on. The system then, based on those checkboxes, adds the appropriate <script> and <style> tags. Overall less code to send to the browser, more flexibility for themers, and more logical grouping of resources.
I now await someone telling me why the above is dumb. :-)
It occurred to me after I sent this that it's dumb because whether or not to use a given module's CSS or JS file is not something that should be user configurable. It should be theme-configurable only, otherwise the behavior could be unpredictable. (MyTheme expects YourModule.css to not be active but it is, or expects it to be active but it isn't.) So forget admin/modules. Instead, a given theme can itself override a module's CSS/JS file by simply providing one of its own with the same name. So if mytheme wants to override yourmodule's default-provided CSS, it can do so by simply providing its own yourmodule.css file. If it wants to just remove that styling completely and not provide its own version, just include an empty yourmodule.css file. That could happen auto-magically or via a required callback function or declaration a la the way theme_* files are overridden. Alternatively, if people don't like magic names, modules could declare their css files via a very simple hook_styles() and JS via a simple hook_scripts(), both of which return a linear array of paths to the files they provide. That would allow multiple files per module to allow a breakup into mymodule-structure.css and mymodule-appearance.css, for instance. The theme override would be done the same way. In either case, the information would be cached per-theme and only rebuild when the module list or theme list changed. We could probably cache the entire <style> and <script> strings pre-rendered and be done with it. Thoughts? Ber, would that take care of the "I don't want JS" issue you bring up? -- 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