-
totten authored
tldr: It's easier to declare `hook_civicrm_buildAsset` listeners at a high-level. Asset building can use two modes -- production mode writes a static file to disk when it's being reference. Debug mode just generates a URL for a web-service (which in turn dynamically renders the content in a separate page-view). If the only mode were production mode, then the code would be on pretty solid ground. We could even simplify things a lot by changing the AssetBuilder contract to replace the hooks with callbacks, as in: ```php Civi::service('asset_builder')->getUrl('crm-menu.css', function() { return '...the css code...'; }); ``` Why have a hook? Because hooks are generally context-free and always-available. If we use debug-mode (or if we add a feature to warm-up the caches during deployment), then we'll want to fire that hook from a different context (e.g. web-service or CLI), and the hook-listener needs to be available in those other contexts. It would be nice if we could declare hooks generally without needing to edit the `Container.php` mega-file (e.g. maybe some kind of annotation). But, for the moment, I think this is the best spot that we have in `civicrm-core` for ensuring that hook listeners are fully/consistently registered.
f22fb451