Moving eBookConfig logic to Runestone

[Andrew Scholer]

Currently PreTeXt writes out a chunk of Javascript (the eBookConfig object) to HTML pages that Runestone needs to provide information from the server to JS running on the page.

Some values in that object are hard coded. Some are paceholds for RS to fill in. A very few are determined by PTX (and are for the most part already known to the server).

I propose simplifying the PTX side to something like this:

eBookConfig = {{ book_config | safe }};

RS will build what it needs and drop the entire dict into place.

Wins:

• That object will soon need to be generated/used from more places. Not all of them want/need the same values in eBookConfig. This is currently proving to be brittle. 
• RS features that need to pass info from server to page no longer need to do a PTX PR to update the eBookConfig to allow for that.

Challenges:

• We may have to pass one or two more values through the manifest to reflect publisher/book info (e.g. scratch activecode language).

I've already talked to Brad. Any concerns from others before I look into this deeper?

[Rob Beezer]

Any impact of this change for non-Runestone-hosted builds?

On 7/1/26 14:39, Andrew Scholer wrote:
> Currently PreTeXt writes out a chunk of Javascript (the eBookConfig object) to
> HTML pages that Runestone needs to provide information from the server to JS
> running on the page.
>
> Some values in that object are hard coded. Some are paceholds for RS to fill in.
> A very few are determined by PTX (and are for the most part already known to the
> server).
>
> I propose simplifying the PTX side to something like this:
>
> eBookConfig = {{ book_config | safe }};
>
> RS will build what it needs and drop the entire dict into place.
>
> Wins:
>

> * That object will soon need to be generated/used from more places. Not all of

> them want/need the same values in eBookConfig. This is currently proving to
> be brittle.

> * RS features that need to pass info from server to page no longer need to do

> a PTX PR to update the eBookConfig to allow for that.
>
> Challenges:
>

> * We may have to pass one or two more values through the manifest to

> reflect publisher/book info (e.g. scratch activecode language).
>
> I've already talked to Brad. Any concerns from others before I look into this
> deeper?
>

> --
> You received this message because you are subscribed to the Google Groups
> "PreTeXt development" group.
> To unsubscribe from this group and stop receiving emails from it, send an email
> to pretext-dev...@googlegroups.com <mailto:pretext-
> dev+uns...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/pretext-dev/
> CACm44N9Sqkv88%2BFZfbGxL0ypqqELbvEgkApx%2BqkSY3RHNcuEAA%40mail.gmail.com
> <https://groups.google.com/d/msgid/pretext-dev/
> CACm44N9Sqkv88%2BFZfbGxL0ypqqELbvEgkApx%2BqkSY3RHNcuEAA%40mail.gmail.com?
> utm_medium=email&utm_source=footer>.

[Andrew Scholer]

We likely would need to leave some minimal amount of information in their eBookConfig.

The goal in that pathway though runestone-header would be to get down to a few lines of meaningful values (e.g. runestone_version and html-scratch-activecode-language). The (slowly growing) list of placeholders that are hardcoded to ''/null/false would go away.

I'm still chewing on the best way to implement this with no timing issues on PTX updates, book builds, and Runestone updates.

To unsubscribe from this group and stop receiving emails from it, send an email to pretext-dev...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/pretext-dev/MTAwMDAwOS5iZWV6ZXI.1783015135%40pnsh.