Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Current »

Wichtige Elemente des ECUI Clients sind hier beschrieben. Das ermöglicht ein besseres Verständnis für den Code aus dem bereits vorher zur Verfügung gestellten Schnelleinstieg mit Application Template.

Application Setup

Quino is leaning onto the general application approach that is also present in Quino-Standard and Quino-WebAPI.

An app normally wants to configure the modules it needs to run. The QuinoApplicationRoot component does most of the heavy lifting there for you. You can configure the setup of the app in the setup callback that has to be passed into the props of the component.

For most apps something like this will be sufficient:

QuinoCoreModule.use(app);
UIModule.use(app);
DevExpressModule.use(app);

The final implementation then looks something like this:

       <QuinoApplicationRoot setup={(app) => {
                QuinoCoreModule.use(app);
                UIModule.use(app);
                DevExpressModule.use(app);
            }} onReady={(app) => {
                // Quino is ready and startup has been excuted.
            }}>
                <YourComponent />
       </QuinoApplicationRoot>

Service registrations

Sometimes it's necessary to override standard services to customize the behaviour. The application provides methods to do so.

IApplication.register<TService>(identifier: Symbol, TImplementation): IApplication
IApplication.registerSingle<TService>(identifier: Symbol, TImplementation): IApplication
IApplication.registerConstant<TService>(identifier: Symbol, TImplementation): IApplication

An actual override could look like this:

IApplication.register<IRequestBuilder>(QuinoCoreServiceSymbols.IRequestBuilder, RequestBuilder);
IApplication.registerSingle<ILogger>(QuinoCoreServiceSymbols.ILogger, ConsoleLogger);
IApplication.registerConstant<Storage>(QuinoCoreServiceSymbols.IStorage, localStorage);

Startup actions

The Quino application supports startup actions that can be used to execute actions before the app is ready. The following methods are available:

IApplication.registerStartupAction(actionIdentifier: Symbol, (app) => {
            // Initialize your service and return a Promise or void.
        })

If you want to disable a startup action you can do so:

IApplication.unregisterStartupAction(actionIdentifier: Symbol);

Per default actions registered by the application will execute in parallel. This can be configured by adding additional groups. Behind the scenes all actions that register via the application get assigned to the ApplicationStartupGroup. To register an additional startup group which will execute after all other groups:

IApplication.registerStartupGroup(groupSymbol: Symbol);

To move an action to the specific group you can do so:

IApplication.registerStartupAction(actionIdentifier: Symbol, (app) => {
            // Initialize your service and return a Promise or void.
        }).moveTo(groupSymbol);

Reducers

Quino provides a set of reducers that provide some convenience functions.

To use a service registered in the IoC:

const metaService = useService<IMetadataTree>(QuinoCoreServiceSymbols.IMetadataTree);

Your component must be a child of the QuinoApplicationRoot.

Retrieve the label settings which are resolved over the IQuinoLabelConfigurationService and the ILabelSettings:

const labelSettings = useLabelSettings(element);

To retrieve metadata related to the IMetaElement:

const { readOnly, required, enabled } = useMetadata(metaProperty, bookmark.genericObject);

To get the related data source from an IMetaRelation:

const source = useRelatedSource(metaRelation, bookmark.genericObject);

To use a promise inside a component:

const [loadResult, error] = usePromise<TDataGridLoadResult, any>(() => loadData(), [metaClass]);

Storage

here are three main storage types supported:

  • InMemoryStorage - only store the data while the app is in use. A refresh of the browser will discard the settings.

  • LocalStorage - working according to the standard defined here.

  • PersistentStorage - user based settings that are stored in the database if the client is configured accordingly.

Each storage is registered with it's own symbol and can therefore be overridden with a different implementation. For example if a server does not support the persistent settings the LocalStorageService could be registered to take place for the PersistentStorageService.

More specialized components that rely heavily on the usage of settings normally offer their own settings service to allow more specific customization of the behavior.

  • No labels