forked from civicrm/civicrm-core
-
Notifications
You must be signed in to change notification settings - Fork 1
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
CollectionAdderTrait - Use secondary ordering more akin to CRM_Core_R…
…esources This is a very subtle behavioral change. To understand it, we must consider the traditional ordering in `CRM_Core_Resources::addScriptUrl()` and `CRM_Core_Region::add()`. Compare these two examples: ``` Civi::resources()->addScriptUrl('http://example.com/foo.js', 100, 'page-footer'); Civi::resources()->addScriptUrl('http://example.com/bar.js', 100, 'page-footer'); CRM_Core_Region::instance('page-footer')->add([ 'scriptUrl' => 'http://example.com/foo.js', 'weight' => 100, ]); CRM_Core_Region::instance('page-footer')->add([ 'scriptUrl' => 'http://example.com/bar.js', 'weight' => 100, ]); ``` You might expect this to output `<SCRIPT>`s in the same order. After all, the examples use the same URLs, the same weights, and the same procedural/natural order. Moreover, `Civi::resources()` is just a wrapper for `CRM_Core_Region`. Surely they were the same! They were not. The output order would differ. The reason is that the ordering had two keys (`weight,name`), and the secondary-key (`name`) was hidden from us: * In `CRM_Core_Resources::addScriptUrl()`, the default `name` was the URL. This was handy for de-duping resources. * In `CRM_Core_Region::add()`, the default `name` was a numeric position. This made it behave like procedural/natural-ordering. Of course, the goal in this branch is to make various collections support the same methods and the same behaviors. But they didn't agree before, so something has to give. Either: 1. Standardize on the behavior of `Resources::addScriptUrl()` and change `Region::add(scriptUrl)`. 2. Standardize on the behavior of `Region::add(scriptUrl)` and change `Resources::addScriptUrl()`. 3. Embrace a split. All `CRM_Core_Resources::add*()` behave one way, and all `CRM_Core_Region::add*()` behave another. 4. Embrace a split. All rich adders (`*::addScriptUrl()`) behave one way, and all generic adders (`*::add()`) behave another. This developmental branch has been using `#3`. The patch changes it to `#4`. Both splits achieve backward compatibility wrt `Resources::addScriptUrl()` and `Region::add(scriptUrl)`. The difference is that `#4` allows us to have the same behavior in all collections (regardless of subtype), which means that collections can be more interoperable and share more code. From my POV, it's still quirkier than `#1` or `#2`, but it's not as quirky as `#3`.
- Loading branch information
1 parent
8d46933
commit 8b7abdb
Showing
3 changed files
with
39 additions
and
20 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters