LivelyKernel / LivelyKernel/lively.next
Local configuration of frozen pages
- Dominant language
- JavaScript
- Stars
- 90
- Forks
- 20
- PR merge metrics
- No merged PRs in 30d
Description
**What would you like to achieve?**
I'd like to have a configuration file for a Lively application. AFAICT, currently remote URLs must be hardcoded into Lively pages. The specific use case that I have is that I have a server which is going to deploy a couple of Lively pages and a bunch of other stuff. The Lively page must call back to the server to store/publish user dashboards. The issue is that I want a separate server per customer, and the server is going to store stuff appropriately for the customer. So the Lively page will have to make a request to `https:///publish`. ATM, I'm hardcoding the URL and a secret into `$world.execCommand("open browser", {moduleName: "undefined", packageName: "engageLively--galyleo-dashboard", codeEntity: "secret"});` which is obviously (a) insecure; and (b) requires a recompile for each customer. I went into the frozen-file directory to find out where the code was, and it was in a compiled file. Now, I could do some post-compilation sed scripts on this file, but this seems pretty kludgy.
**How are you trying to achieve that**
Frankly, the way to achieve this seems pretty easy to me: just have a `local_settings.js` file which is loaded on a per-deployment basis. Where to put this with respect to the compiled files will have to be well-documented.
**Alternative solutions**
If applicable, what other solutions have you tried?
**Additional Resources**
Please provide links to any custom code that might be necessary to grasp your problem. Screenshots of custom component, etc. are also appreciated.
**Version**:
154aad128403ef1d7b29332cc5449fb7a6f4a549
Contributor guide
Research direction
Start by examining the frozen-file directory and the compiled file where the hardcoded remote URL and secret currently reside. Trace how a frozen Lively page is loaded, then determine where a per-deployment local_settings.js could be loaded and documented; done means customer-specific settings work without recompiling each page.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript
- Domain
- devops, web-dev
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100