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
]
});
});