The site implementation is the structure for customizing a CEF
storefront. All pieces of the application are available for modification
and should stay in source control. CEF core should never be modified for
any single project. From the site implementation, most aspects of CEF
can be customized and expanded to suit client needs.
Through the base app configuration, certain values can be set (like API
path) for the specific application. Any library configuration, API keys,
default values, etc. should be kept in the application configuration:
<b>/src/app/config/cef-config-service.ts</b>.
The config class contains readonly objects holding primitive values. Add
new top-level objects as needed.
The base routes that point to entry components in the application can be
customized to suit the client by editing the
<b>/src/app/app.routes.ts</b> file. This allows the URL for something
like <i>/catalog</i> to be changed to <i>/store</i>. Sub-routes to a
component that manage state are attached to the component itself and
will stay relative to the entry path.
Any number of new components, services, and directives can be created in
the client site implementation. Keep in mind that these pieces could
become candidates for inclusion back into CEF core, so follow good
organization and coding practices. For ease of management, add feature
modules as they make sense.
As of Angular 2.3 component classes support inheritance. More to come.
Service classes can be extended and then the dependency injection
configured to use the new class. More to come.
How much DI info should I put here?
The appearance of CEF core can be modified without modifying the library
itself. During the build process the paths for templates and css files
are compared with a directory in the site implementation. If a match is
found, the contents of the alternate file will be used.
The base directory for comparison is <b>/src/app/cef-custom</b> and it
matches with <b>node_modules/cef</b>. For the process to work, the
filename and path must match. For example: the catalog template is
located in <b>~/catalog/cef-catalog/cef-catalog.component.html</b>. To
override it you will need to create the nested directories and the file
in the cef-custom directory. If the dev server is running, the project
should automatically recompile.
Besides .css files referenced in the @component decorator being
overridden, CSS pre-processors are supported. If a .scss or .less file
is used, it will be processed after inclusion.
This override magic trick is a custom feature developed in-house that
modifies angular-cli, and there is always a possibility that an update
could break it. This is how it works:
If you are overriding core CEF templates, it is likely that non-core
components or directives will be used. Without registering these
components within CEF core, unknown directive errors will be thrown. For
this purpose there is <b>/src/app/cef-custom/cef-custom.module.ts</b>.
It is an angular module where these components can be declared. Like
with template overrides, a node_module reference is used for loading
the file during the build project. This circular reference introduces
one quirk-- The import statements required by the angular module must be
relative to the module path as it is at compile time. This means that
the paths begin with <b>../../src/app/</b>. Your editor may complain
about the paths being incorrect, so be aware that debugging could be
more difficult and double-check your import statements if you encounter
problems.