fetching non-existent source .ptx files

[Alex Jordan]

I discovered the following while trying to build ORCCA locally. I do
not see the issue in the PreTeXt example documents I looked at, but I
do see it when I visit Active Calculus:
https://activecalculus.org/single/sec-1-1-vel.html

There is a console error that originates from pretext_add_on.js. There
is an assumption that because the file
activecalculus.org/single/sec-1-1-vel.html
exists, then at the same location will be a file:
activecalculus.org/single/sec-1-1-vel.ptx

The javascript attempts to fetch this file, but it doesn't exist (at
least not at that location) and this leads to the console error. I
would guess this all has to do with the CAT, but I'm not sure.

For my local ORCCA build, I get a second similar error originating from edit.js.

Can we change something (either these .js files, or introduce some
processing switch, or both) so that these console errors go away? I
could probably just not care about them, except that I am trying to
set up some new contributors with a pristine workflow.

[Rob Beezer]

Andrew R was worked up about this a few months ago. Did you find that thread?

I was about to comment that when you run the CLI server to view HTML output (on
CoCalc) you get a bunch of 404 messages in your terminal for thee files as you
move for page to page in your output.

This supports the editing experiments David F is working on.

I'm happy to do whatever is needed on the XSL side, but the ball is in David's
court on this one. (I forget where we are right now, I did not go back to
look.) IIRC, am generating those files for the live sample article to support
David's work.

Rob

[Alex Jordan]

> Andrew R was worked up about this a few months ago. Did you find that thread?

No, I hadn't noticed.

Maybe not the best idea, but the XSL side could have a stringparam for
editing enabled or disabled. I would guess disabled by default while
the editing experiments are still experiments. And then this writes
some signal into the HTML. And then David's javascript could do what
it does conditionally on the presence of that signal.

> --
> 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.
> To view this discussion on the web visit https://groups.google.com/d/msgid/pretext-dev/8f8c8858-70cb-99a2-6029-dbea23066aa1%40ups.edu.

[David Farmer]

Maybe if I use try..catch ?

[Alex Jordan]

Another possibility: is the editing javascript in the process of
moving out of pretext_add_on.js and into edit.js? If that's happening,
then the stringparam on the XSLT side could simply add or not add the
line that loads edit.js.

Just saw David's try..catch mesage. In the future, if a user actually
wants editing but has neglected to put their source .ptx files in the
right place, would try..catch be problematic?

[Rob Beezer]

On 11/12/22 13:33, Alex Jordan wrote:
> In the future, if a user actually
> wants editing but has neglected to put their source .ptx files in the
> right place, would try..catch be problematic?

Now, that would be a support nightmare!

The XSL generates those *.ptx files. With like two lines of code. ;-)

[Alex Jordan]

> The XSL generates those *.ptx files.

In that cases another option is changing the CLI to track those files
that are made and make sure they are copied to the right place when
building HTML.

> --
> 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.

> To view this discussion on the web visit https://groups.google.com/d/msgid/pretext-dev/1915c4d7-593e-0f55-a2fe-8f52bdb9af3b%40ups.edu.

[Steven Clontz]

The point that the Python http.server output is cluttered by all these 404 server requests is an important one - if the CLI was updated to somehow build those files, we'd not only not remove this clutter (just replace 404s with 200s), but we'd clutter the output directory and endpoint static web host with several files that, as I understand the situation, 99% of authors/readers don't need today.

To view this discussion on the web visit https://groups.google.com/d/msgid/pretext-dev/CA%2BR-jrcYEczMidGb%3DNxpr1kon1f3Fx9sDu1NdYS2_-NPDFegCQ%40mail.gmail.com.

[Rob Beezer]

This is all under the control of a string parameter "debug.editable". So files
are not being produced unless asked for, such as they are being asked for for
the sample article at David's request (and nobody is generally the wiser?).

It is the code that goes looking for these files and not finding them, that is
raising the console (and server) errors, I guess.

Since we have this flag, the request for editability is known to the XSL and we
can do whatever we want (as usual!) - write a small JS file to set a variable,
for example. Or only electively include the necessary JS for editing. Or ...

So the ball is in David's court as to what is the best solution for *his* project.

These are all experiments, so it is premature to think about the
role/responsibility the CLI will have down the line. We *do* want to make the
*current* CLI experience a good one, and minimize support queries.

Rob

> <mailto:pretext-dev%2Bunsu...@googlegroups.com>.

> > To view this discussion on the web visit

> https://groups.google.com/d/msgid/pretext-dev/1915c4d7-593e-0f55-a2fe-8f52bdb9af3b%40ups.edu <https://groups.google.com/d/msgid/pretext-dev/1915c4d7-593e-0f55-a2fe-8f52bdb9af3b%40ups.edu>.

>
> --
> 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%2Bunsu...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/pretext-dev/CA%2BR-jrcYEczMidGb%3DNxpr1kon1f3Fx9sDu1NdYS2_-NPDFegCQ%40mail.gmail.com <https://groups.google.com/d/msgid/pretext-dev/CA%2BR-jrcYEczMidGb%3DNxpr1kon1f3Fx9sDu1NdYS2_-NPDFegCQ%40mail.gmail.com>.

>
> --
> 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...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/pretext-dev/CAOWT6TikN%2BsGLQ2fou78EkfJf%3D7whRrxTfVWWtpV3s4TA3J6%3Dw%40mail.gmail.com <https://groups.google.com/d/msgid/pretext-dev/CAOWT6TikN%2BsGLQ2fou78EkfJf%3D7whRrxTfVWWtpV3s4TA3J6%3Dw%40mail.gmail.com?utm_medium=email&utm_source=footer>.

[Steven Clontz]

Trick I've used: set a global variable in the html like

<script>let editable=true</script>

Then David can check for this before doing anything CAT related.

To unsubscribe from this group and stop receiving emails from it, send an email to pretext-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pretext-dev/ac591309-c849-21a4-59a6-5e7538e69b2d%40ups.edu.

[Rob Beezer]

On 11/12/22 16:33, Steven Clontz wrote:
> <script>let editable=true</script>

Hadn't dawned on me that it could be that minimalist. ;-)

Rob

[sief...@gmail.com]

I think, as people ask for JS customizations more generally, we need some sort of `config` object that's injected into the JS on each page. Then the Pretext JS would be configured in a similar manner to MathJax.

I might suggest

```
<script>
window.PretexConfig = typeof PretextConfig === "undefined" ? {} : PretextConfig;
Object.assign(PretextConfig, {
editable: false,
});
</script>
```

That should be pretty robust (e.g., if someone defines a PretextConfig via some custom processing, this code should only add to it and not override it) and will allow us to easily add more things that people want configured (I am against lots of options, because they add complexity, but options are better than a product people don't use).

Also, all options should be phrased such that `false` is the default. That way, the JS can be updated and nothing should change unless someone recompiled ptx.

[David Farmer]

Okay, lots of good points here.

Since we are getting back on track with the overhaul, and once the
CSS is a little better we will turn to the JS, I decided to be minimal
and just go with checking for a variable before fetching that file.

That variable does not exist, so the experimental editing feature
is not available for the sample article. I'll send a pull request.

Switching to using a PretextConfig is easy enough to do later.
I think that will also help with publisher styling options,
readability options, etc.

I also commented out a bunch of messages that were polluting the
console.

David

ps. It seems that it is impossible to suppress a 404 error message,
so any solution has to involve not trying to fetch that file when
it is not supposed to exist.

> --
> 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.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/pretext-dev/d82cbf7f-46cb-dc1c-d66f-a411a6da93c8%40gmail.com.
>

[Rob Beezer]

On 11/12/22 17:56, sief...@gmail.com wrote:
> I think, as people ask for JS customizations more generally, we need some sort
> of `config` object that's injected into the JS on each page.

Right, Runestone has its "eBookConfig", which we (PreTeXt) set two different
ways, depending on if HTML is being built for general use, or to be hosted on a
Runestone server. I think the syntax is such that it is not quite as robust as
suggested here, but perhaps it doesn't need to be. (I'm straying above my pay
grade.)

Thanks for the good suggestion.

Rob

[Rob Beezer]

On 11/13/22 05:24, David Farmer wrote:
> That variable does not exist, so the experimental editing feature
> is not available for the sample article.  I'll send a pull request.

Or just tell me what to do, might be easier for you and no more work for me.

Rob

[Steven Clontz]

I like Jason's suggestion of a flexible config object long-term; adopting it now reduces the need for complicated checks for backwards compatibility later (vs my original one-liner).

Steven Clontz

https://clontz.org - steven...@gmail.com

--
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.

To view this discussion on the web visit https://groups.google.com/d/msgid/pretext-dev/e4394307-679e-b606-2483-a0897293b87c%40ups.edu.

[Rob Beezer]

On 11/13/22 14:42, Steven Clontz wrote:
> I like Jason's suggestion of a flexible config object long-term;

Me too.

> adopting it now
> reduces the need for complicated checks for backwards compatibility later (vs my
> original one-liner).

But since David versions his JS and we produce HTML consistent with the version
we specify, isn't this sort of back-ward compatiity danger moot?

Variable is orphaned for config object, JS version is incremented - old/stale
and new HTML output both behave?

Rob