Skip to main content

Portal Routing

danger

This is a concept that has been under development, conceptually for some and there are some code supporting the concept. the following section is supporting portal by config concept but not yet fully implemented on both fronted and backend.

The base portal routing is simple, but can be expanded by configuration.

lets take the Project Portal as an example and then se the compassion to how the Resource Allocation Portal could be configured.

The example under shows the Project Portal configuration

    enablePortalConfig(config, (builder) => {
builder.setConfig({
portalId: portalConfigEnv.portalId
portalEnv: portalConfigEnv.fusionLegacyEnvIdentifier,
});
builder.setRoutes({
root: {
pageKey: 'project-portal',
},
routes: [
{
path: 'project/*',
pageKey: 'project',
messages: {
errorMessage: 'Fail to load project page',
},
children: [
{
messages: {
errorMessage: 'Fail to load project page',
},
path: ':contextId',
pageKey: 'project',
},
],
},
{
path: 'facility/*',
pageKey: 'facility',
messages: {
errorMessage: 'Fail to load facility page',
},
children: [
{
messages: {
errorMessage: 'Fail to load facility page',
},
path: ':contextId',
pageKey: 'facility',
},
],
},
],
});
});


the project portal will not reserve any applications as it context-firs approach.

The example under shows the Resource Allocation Portal

    enablePortalConfig(config, (builder) => {
builder.setPortalConfig({
portal: {
id: 'resource-allocation',
name: 'Resource Allocation',
},
routes: {
root: {
pageKey: 'resource-allocation-landingpage',
},
routes: [],
},
apps:[
// available app manifests
]
});
});