Skip to content

Commit

Permalink
docs: put uppercase for cms and angular (#1614)
Browse files Browse the repository at this point in the history
  • Loading branch information
@matthieu-crouzet
matthieu-crouzet authored Apr 10, 2024
2 parents 1fda6ee + 12b1497 commit 73b2826
Show file tree
Hide file tree
Showing 21 changed files with 171 additions and 171 deletions.
2 changes: 1 addition & 1 deletion docs/README.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -19,7 +19,7 @@ The documentation is sorted by topic but in the table below, you shall find the
| @o3r/dynamic-content | Mechanism to retrieve media and data depending on the host or a server specific url | @o3r/core <br/> @o3r/dev-tools | [DYNAMIC_CONTENT](./dynamic-content/DYNAMIC_CONTENT.md) <br/> [LOCALHOST_MIDDLEWARE](./dynamic-content/LOCALHOST_MIDDLEWARE.md) |
| @o3r/eslint-plugin | In-house eslint plugins to use in your own eslint configuration | N/A | [eslint-plugin](./linter/eslint-plugin.md) |
| @o3r/extractors | Utilities to extract your application metadata to interact with your CMS | @o3r/core <br/> @o3r/dev-tools | |
| @o3r/forms | Utilities to enhance angular form (asynchronous decorator, additional validator, error store...) | @o3r/core <br/> @o3r/dev-tools | [README](./forms/README.md) <br/> [FORM_ERRORS](./forms/FORM_ERRORS.md) <br/> [FORM_STRUCTURE](./forms/FORM_STRUCTURE.md) <br/> [FORM_SUBMIT_AND_INTERCOMMUNICATION](./forms/FORM_SUBMIT_AND_INTERCOMMUNICATION.md) <br/> [FORM_VALIDATION](./forms/FORM_VALIDATION.md) |
| @o3r/forms | Utilities to enhance Angular form (asynchronous decorator, additional validator, error store...) | @o3r/core <br/> @o3r/dev-tools | [README](./forms/README.md) <br/> [FORM_ERRORS](./forms/FORM_ERRORS.md) <br/> [FORM_STRUCTURE](./forms/FORM_STRUCTURE.md) <br/> [FORM_SUBMIT_AND_INTERCOMMUNICATION](./forms/FORM_SUBMIT_AND_INTERCOMMUNICATION.md) <br/> [FORM_VALIDATION](./forms/FORM_VALIDATION.md) |
| @o3r/localization | Provide a fallback language/translation support and debug tools | @o3r/core <br/> @o3r/dev-tools | [LOCALIZATION](./localization/LOCALIZATION.md) <br/> [CMS_ADAPTERS](./cms-adapters/CMS_ADAPTERS.md) |
| @o3r/logger | Bridge to target different logger (logrocket, fullstory, smartlook) with a common interface | N/A | [LOGS](./logger/LOGS.md) |
| @o3r/mobile | Helpers and store to integrate Capacitor into your Otter application. <br/> Integration with the pCloudy API for e2e testing on real devices. | @o3r/core <br/> @o3r/logger | |
Expand Down
4 changes: 2 additions & 2 deletions docs/application/REDUCED_MOTION.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -2,7 +2,7 @@
The ``@o3r/application`` module provides ``prefersReducedMotion()`` -- a helper that identifies the computer animation preferences.
This setup is generally used in the scope of accessibility as some users find it difficult to interact with pages with many animations.

To respect their choice, the application's angular animations should follow the computer preferences.
To respect their choice, the application's Angular animations should follow the computer preferences.

This can be done in the BrowserAnimationsModule's configuration as follows:
```typescript
Expand All @@ -25,7 +25,7 @@ export class AppModule {}

**Note:** If you face timing issues in flaky e2e tests that might be linked to animation delays, you can force the reduced
motion browser setup in your test configuration.
Here is an example with a custom playwright configuration that will disable the angular animations:
Here is an example with a custom playwright configuration that will disable the Angular animations:
```typescript
const config: PlaywrightTestConfig = {
timeout: 5000,
Expand Down
4 changes: 2 additions & 2 deletions docs/cms-adapters/CMS_ADAPTERS.md
View file
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
# Otter CMS adapters

Extract and generate Otter related data to integrate with a cms
Extract and generate Otter related data to integrate with a CMS

## Extractors

Expand Down Expand Up @@ -188,7 +188,7 @@ Here is an example:
// angular.json
...
"extract-rules-engine": {
"builder": "@o3r/rules-engine:extractor", // otter cms adapters builder
"builder": "@o3r/rules-engine:extractor", // otter CMS adapters builder
"options": {
"tsConfig": "./tsconfig.cms.json", // ts config file used by the builder
"libraries": [ // libraries containing facts included in the app
Expand Down
6 changes: 3 additions & 3 deletions docs/components/COMPONENT_STRUCTURE.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -158,7 +158,7 @@ There is a dedicated [fixtures documentation](./FIXTURES.md) to explain in detai

### Unit test (`*.spec.ts`)

Unit test for the component using angular TestBed suite.
Unit test for the component using Angular TestBed suite.

### Integration test (`*.int-spec.ts`)

Expand All @@ -181,10 +181,10 @@ Template of the component.

### Component class (`*.component.ts`)

This is the core of a component. Here is where you have the angular decorators for the component itself.
This is the core of a component. Here is where you have the Angular decorators for the component itself.
By default, it implements Configurable with generic of the class defined in my `.config.ts`, as explained in [Configuration](#configuration) .
It also implements the context, defined in `.context.ts`, as explained in [Context](#context).
We are compliant with angular best practice, and we enforce rules using ts-linter.
We are compliant with Angular best practice, and we enforce rules using ts-linter.

### Module (`*.module.ts`)

Expand Down
2 changes: 1 addition & 1 deletion docs/configuration/CONFIGURATION_SUPPORTED_EXTRACTOR.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -46,7 +46,7 @@ For an up-to-date documentation, run `ng help @o3r/components:extractor`
__Note:__ This options will not search for the duplicate configurations in libraries.

The __strict mode__ option should be used for production builds, it will throw an error if something not supported by the
cms is found in the config. You can set it to `false` to allow the generation of metadata including the unknown types to
CMS is found in the config. You can set it to `false` to allow the generation of metadata including the unknown types to
ease issues fixing, and with the errors logged as warnings.

Here is an example on a library
Expand Down
52 changes: 26 additions & 26 deletions docs/configuration/OVERVIEW.md
View file
Original file line number Diff line number Diff line change
@@ -1,31 +1,31 @@
# Configuration mechanism

The aim of this document is to help developers to implement configuration inside components, in order to be compliant
with __cms architecture__. This will give the possibility to __Business Analyst__ to configure the
with __CMS architecture__. This will give the possibility to __Business Analyst__ to configure the
application/components.

## Component config types

```
store config
│ Input config
│ (from parent)
│ (from parent)
│ Component default config │
│ (in config.ts file) │
│ │ │
│ overrides │ │
└──────────────────────────────>│ │
│ │
│ │
global config │ │
(no common props) │ │
│ │ │
│ │ │
│ merge │ │
(no common props) │ │
│ │ │
│ │ │
│ merge │ │
└──────────────────────────────>│ │
│ │
│ │
│ overrides │
│ │
│ overrides │
│<────────────────────────────────────
│
↓
Expand All @@ -51,7 +51,7 @@ A component will have to handle different types of configurations.
### Global config

- The common configuration is the one used in multiple components (it can be a date format, price display, type of input
form fields from an angular material input element ...)
form fields from an Angular material input element ...)
- A common configuration is defined in every library. The application common configuration (__global config__) will be
the result of the __merge of all common__ configurations.
- The common configuration is __not overridden__ at component type (there will be no properties with the same name in
Expand Down Expand Up @@ -99,12 +99,12 @@ __No need of rebuild/redeploy the app__

- At __library__ level we have the config for components (__blocks, components, elements__).

A block component class should implement __Block__ interface from __@o3r/core__ to be identified by cms adapter
A block component class should implement __Block__ interface from __@o3r/core__ to be identified by CMS adapter

- At application level:

__Page config__ - each page component class should implement __Page__ interface available in __@o3r/core__ in order to
be identified by cms adapter
be identified by CMS adapter

__Application config__
The application can have 2 types of configs depending on the use cases: __pre-bootstrap__ and __runtime (
Expand All @@ -113,23 +113,23 @@ post-bootstrap)__ config
Pre-bootstrap config

- Defined in one interface which will extend __AppBuildConfiguration__ interface available in __@o3r/core__ in order
to be identified by cms adapter
- PreBootstrap config object is used for configurations needed before loading the angular app component, and it will be
injected by the cms in the index.html body tag data-bootstrapconfig as a data attribute
to be identified by CMS adapter
- PreBootstrap config object is used for configurations needed before loading the Angular app component, and it will be
injected by the CMS in the index.html body tag data-bootstrapconfig as a data attribute

Runtime config

- Defined in one interface which will extend __AppRuntimeConfiguration__ interface available in __@o3r/core__ in order to
be identified by cms adapter
- The object defined here is used as configuration for the application ( ex: angular material form field appearance
be identified by CMS adapter
- The object defined here is used as configuration for the application ( ex: Angular material form field appearance
global on the app)

## Examples

### Default config

Possible example of default config file for a component.
You can have a look at [configuration types supported by cms extractor](./CONFIGURATION_SUPPORTED_EXTRACTOR.md) for more
Possible example of default config file for a component.
You can have a look at [configuration types supported by CMS extractor](./CONFIGURATION_SUPPORTED_EXTRACTOR.md) for more
details about the types.

```typescript
Expand Down Expand Up @@ -169,7 +169,7 @@ export const MY_DEFAULT_CONFIG: MyConfig = {
### Component file (*.component.ts)

Here is an example of configuration in the component, note that dynamicConfig$ is there for the configuration service
and config$ for the configuration store
and config$ for the configuration store
This part is already handled by our [component generator](../core/OTTER_ANGULAR_TOOLS.md) if you are use it to generate your
components

Expand All @@ -193,7 +193,7 @@ export class MyComponent implements DynamicConfigurable<MyConfig> {
// The configuration service is used here to do the merge between the default config with the config from store
@Optional() configurationService?: ConfigurationBaseService
) {
// Register the component config (default) in the store. ConfigurationObserver is used to get the config stream.
// Register the component config (default) in the store. ConfigurationObserver is used to get the config stream.
// The configService will do the merge between the default config (MY_DEFAULT_CONFIG) and possible config which is already in the store for this component identified by (MY_CONFIG_ID)
this.dynamicConfig$ = new ConfigurationObserver<MyConfig>(MY_CONFIG_ID, MY_DEFAULT_CONFIG, configurationService);
this.config$ = this.dynamicConfig$.asObservable();
Expand Down Expand Up @@ -309,7 +309,7 @@ export class AppComponent implements OnInit, OnDestroy {
}

// As mentioned above, we have to merge common configs coming from libraries and to pass the result as global config to the store
// The config service has a method which is doing this
// The config service has a method which is doing this
private registerDefaultGlobalConfig() {
// Compute the global config based on all common configuration from libraries
const global = {...AREA_1_CONFIG_DEFAULT, ...AREA_2_CONFIG_DEFAULT};
Expand All @@ -331,7 +331,7 @@ __Default configuration__ for a component type is the one taken from the .config

__Static configuration__ is the one injected in the index.html of the application.

- It's the configuration which is modified inside the cms or by hand (implementation teams)
- It's the configuration which is modified inside the CMS or by hand (implementation teams)
- It will be injected as a data attribute on the body tag (data-staticconfig). At bootstrap, the value from the data
attribute will be read and the store updated.
- It will override the default configuration
Expand All @@ -352,8 +352,8 @@ __Input config__

__Config priorities__ for a component:

- the highest priority is the one passed as input from a parent component
- the second priority is the priority by component type set in the store
- the highest priority is the one passed as input from a parent component
- the second priority is the priority by component type set in the store
- the lowest priority is the default config set on component (in the config.ts file of the component)

## Runtime debugging
Expand Down
Loading

0 comments on commit 73b2826

Please sign in to comment.