- Variables added via `CRM_Core_Resources` will be loaded as part of a snippet - new variables will be appended to the CRM object, and existing variables with the same name will be overwritten.
- Scripts added via `CRM_Core_Resources` will be loaded as part of a snippet. This may not always be desirable, e.g. if the same snippet is refreshed multiple times it will reload all scripts every time. To avoid a script loading into a snippet one could specify the `html-header` region for the script. See [Resource Reference](/framework/resourcee).
- Scripts added via `CRM_Core_Resources` will be loaded as part of a snippet. This may not always be desirable, e.g. if the same snippet is refreshed multiple times it will reload all scripts every time. To avoid a script loading into a snippet one could specify the `html-header` region for the script. See [Resource Reference](/framework/resources.md).
- Javascript header scripts, notably the wysiwyg editor library, are not loaded automatically, which causes many forms to not work without manually loading the necessary scripts prior to the ajax call.
- If the page/form directly issues a redirect it will prevent ajax from working. Best practice is to not use `CRM_Utils_System::redirect()` but instead use `CRM_Core_Session::pushUserContext()` and allow the core controller to take care of the rest.
@@ -26,6 +26,6 @@ When we look at CiviCRM Tables there are a few patterns that generally hold true
- Every table has a id column which is Auto Increment and therefore unique key for that table
- Columns which reference other tables generally speaking will be named in the format of `other table name` + `_id`. For example in `civicrm_country` there is `address_format_id` which indicates that is references `civicrm_address_format.id`
- Many-to-many relationships use "join tables" as intermediary tables. For example, a contact can have many activity records, and an activity can have many contact records. So the table `civicrm_activity_contact` is used as the glue because it has foreign keys to both.
- In some places CiviCRM defines schema using a construct called [PseudoConstants](/framework/database/schema-definition#table-field-pseudoconstant) which produces some slightly more complex logic
- In some places CiviCRM defines schema using a construct called [PseudoConstants](/framework/database/schema-definition.md#table-field-pseudoconstant) which produces some slightly more complex logic
- Lots of columns reference `civicrm_option_values` when they just need a simple (and user-configurable) list of options. For example, look at `civicrm_contribution` which has a column called `payment_instrument_id`. You'll notice there's no table called `civicrm_payment_instrument`. So in this case the `payment_instrument_id` column actually references the value column in `civicrm_option_values` (but only for records in `civicrm_option_values` with the appropriate `option_group_id`.) Here there is no foreign key, so referential integrity is managed at the application layer, not the database layer.
- Some tables use "dynamic foreign keys". For example, look at `civicrm_note` which has columns `entity_id` and `entity_table`. This is because a note can be attached to different entities (e.g. contact, contribution, etc). So two columns are used to indicate what the note references. Here again, the application layer is responsible for ensuring referential integrity, so you won't find any foreign keys.
@@ -157,7 +157,7 @@ CiviCRM ships with a number of UI widgets and plugins to create standardized "lo
## Test Tools
CiviCRM has uses a couple of main tools to test Javascript Code when a pull request is made against code. This happens along side the [code style checks](/standard/javascript#coding-standards) which are as mentioned above against JsHint
CiviCRM has uses a couple of main tools to test Javascript Code when a pull request is made against code. This happens along side the [code style checks](/standards/javascript.md#coding-standards) which are as mentioned above against JsHint
### Qunit
...
...
@@ -165,7 +165,7 @@ CiviCRM has a small set up of Qunit which is an automated testing system. It's g
### Karma
For testing CiviCRM's Angular implementation in Core, CiviCRM has intergrated some Karma tests into the standard test suite that is run against each Pull request. More information on karma can be found in the [Javascript testing](/testing/javascript/) section of this guide
For testing CiviCRM's Angular implementation in Core, CiviCRM has intergrated some Karma tests into the standard test suite that is run against each Pull request. More information on karma can be found in the [Javascript testing](/testing/javascript.md) section of this guide
