Hi Johannes,
it's clear, that for each tab, a separate WAR file is generated. Because, as you said, each tab within the FirstSpirit Admin Console offers an individual web application for custom "/fs4preview","/fs4staging", "/fs4webedit" and content delivery web applications (where custom application logic is implemented).
What we want to realize is, that each application get's all environment specific configuration files, In consequence we would like to have:
- /fs4preview_<project_id>
- D/Q/P environment configuration included
- /fs4staging_<project_id>:
- D/Q/P environment configuration included
- /fs4webedit_<project_id>:
- D/Q/P environment configuration included
- live web application:
- D/Q/P environment configuration included
The problem: if we want to follow your suggestion, where the configuration offers environment specific configuration forms, all FirstSpirit components that allow a GUI configuration have to be adapted in their implementation. Even the one, that FirstSpirit offers in FirstSpirit standard modules.
Am I right?
It might be better, if no GUI implementation changes might be necessary. To reach that, it might help to offer the Administrator the opportunity to add external configuration files within the GUI. They follow a naming convention like:
- bgn_d.conf
- bgn_q.conf
- bgn.conf
These configuration files are just referenced in the GUI using a variable that is being set dependent on the environment. Then each generated FirstSpirit web application should contain EasyConf to resolve the variable at runtime and load the correct file.
To my understanding this is a feature request for the core FirstSpirit product. Correct?