(REF) CRM_Core_Resources - Move hook declaration from addCoreResources() to Container.php
authorTim Otten <totten@civicrm.org>
Mon, 8 Apr 2019 23:13:48 +0000 (16:13 -0700)
committerTim Otten <totten@civicrm.org>
Tue, 9 Apr 2019 01:06:19 +0000 (18:06 -0700)
commitf22fb451346b41578cda9bb606a713881317ef59
treee958599bb95870e164ff7e87a927e06fe5210856
parentf9e118bfcf14cca61480749052282ef27104ee83
(REF) CRM_Core_Resources - Move hook declaration from addCoreResources() to Container.php

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.
CRM/Core/Resources.php
Civi/Core/Container.php