This is a general life cycle that happens when HAXcms "boots up". When web components are unpacking the contents of what to do it generally will work this way.

- page load, should it be no-js or a web component delivered, preflight
- haxcms-site-builder loads site.json, reads JSON Outline Schema and starts to bootstrap that into a theme, items, title, etc
- Appends a haxcms-editor-builder tag which checks for "context"
- Context is established based on global values for php, nodejs, beaker, etc
- Uses a login end point to check if there's a JWT in the user's local data
- When it finds a backend, it injects a tag to bridge that backend
- HAXeditor gets injected into the correct place in the theme which then all of that unpacks and does its thing

## Event driven architecture

HAXcms allows for jumping in at different core operational steps and reacting to these changes based on an event driven design pattern. This means that an event "fires" in PHP, much like it does in JavaScript and code written to react to it can make changes at that point in the operation.

Here is an example from HAXiam which implements custom configuration event listeners

### Core listeners

Core listeners to influence how the data is constructed. You can add these to your _config/config.php file

- haxcms-init - just after HAXcms bootstraps its initial configuration
- haxcms-site-metadata - when constructing metadata block at the top of the document
- haxcms-connection-settings - for authorized users, this is the block of end points for connecting to and modifying HAXcms logic as far as where data flows.

### Enterprise integrations and SSO

The following hooks allow for supplanting the HAXcms (intentionally) simplistic login system. This allows you to do custom integrations for your organization. HAXiam implements many of these if you need specific examples.

- haxcms-login-test - when a login didn't pass our simplistic built in checks. Useful for enterprise integrations and other SSO methods of access
- haxcms-validate-user - same as login-test except this fires to validate every transaction to ensure the user name matches when decoding the JWT
- haxcms-jwt-get - when we ask for the JWT. This allows SSO to supply the token manually via a different methodology than our core one
- haxcms-refresh-token-get - when our connection is deemed needing to refresh, this supplies the refresh token for when and what that looks like