Basically, the capabilities of any given xLim 2.0 application are defined by the modules that have been loaded. Modules, when they are loaded, can do all sorts of complex things with .NET code:
- Register business objects.
- Register new components with different scopes, ownership, registration procedures (lambda, factory, reflection, instance etc)
- Resolve components registered by other modules and augment them.
We do not care about the specifics as long as the IoC takes care of the registration/resolution and the modules do not break the system.
However, in order to configure the application, we need to know what building-blocks do we get after some modules get loaded (including all the modules they depend on).
This can be simply done by loading the desired assemblies into the IoC and then examining the actual results:
Additionally, the modules can optionally provide some configuration presets for their components. These presets are merged into a single composite schema (basically just a class that is registered in the IoC by the SharedCoreModule that contains all the common functionality) and are also trivial to inspect and validate.
While we are at the schema level, we can also create our own configuration bits and save them to the configuration file for the specific application host.
Additionally, since the container has been actually loaded, we can check out how ViewSchemas would actually look when loaded by the desktop detail/grid views, or how command links would merge together into Ribbon/Bars in different combinations. Basic validation testing also happens here.
The third level of the configuration is a creation of the actual navigation tree. It would reference the configured handlers (optionally overriding some parameters) to build the UI for the Web/Desktop users. This piece is done by the small console client, that connects to the running xLim server as the root user and builds the tree.
Users from the SuperAdmin group normally get the desktop view to modify the existing tree on-the-fly, but it is rarely used and kept only for the situations where it is urgently needed to reconfigure the production system (i.e.: allow manager to edit some fields, disable the workflow rules for some customer, add commands to the menu of the low-level user