New option to copy file/s to Scratch when previewing

Is it possible to get an option to select a file in the resources that can be copied to the scratch area and treated as an external file when in preview.

This would help in testing and avoid some of the CORS denials when previewing.

I can’t see that this would be very hard to do and it does work if you do this manually.

You would probably also need to add a no cache on the files…

Mock up of option. using the file

Image 1,

Preview as external on export copies/aliases file to scratch ) - Off by default.

On ( allows previewing using the file outside of the hype resources and to be served by the Hype web server )

Copy as internal resource on export On by default.
Will be included in the hype resource folder as normal on export

Image 2,

**Preview as external on export - Checked On
Copy as internal resource on export Checked On

Image 3,

**Preview as external on export - Checked On
Copy as internal resource on export Checked Off,
Will Not be included in the hype resource folder as normal on export

How it would be used in the code.

function loadMDs(box,file){
	var txtFile = new XMLHttpRequest();"GET",  "", true);
txtFile.onreadystatechange = function() {
if (txtFile.readyState === 4) { ......

Preview export to scratch.


result in preview without getting a (CORS) cross domain denial.

I’m not sure I quite understand this request - can you clarify what you mean by internal vs. external? (Especially as you can check external and internal at the same time with the mockup).

Presently any items in the Resources Library are copied into the .hyperesources folder at preview and export. If the file is a type like a .md file, Hype doesn’t do anything with it though and it would be your code that would need to load it.

This is for when you have files like the .md file outside of the .hyperesources Folder on a server.

At present it is not fully possible to preview/test this setup properly from within hype.
You normally need to exporting and uploading to a server.

You will also normally not be able to test by just exporting to local disk unless
you can build your own local server.

Some browsers allow you to turn the domain and local file restrictions off but I do not think all make it easy and I have never felt this was a good way to test.

So this is to try and leverage the built in hype server during previews.

The idea is you can drop a file into hype as normal.

The normal intention of dropping a file into hype is that it is copied to the .hyperesources Folderon on export.
You still want this behaviour for most files.

This is the reason I show that as the default option in fig 1.
The checkbox to copy the file to (internal) the .hyperesources folder is selected (on) but not enabled by default.

In fig 2
you now see we have checked the preview as external checkbox, this in turn also enables the second checkbox.

You can now stop the file from being copied to the .hyperesources Folder when exporting if you want as showen in fig3. because you will only be using the file to test and preview with hype but not including the file on final export.

The intention of this is to be able to drop files into hype as normal but additionally have an option to say I only want this file to be copied or aliased to the scratch folder externally/outside of the .hyperesources Folder.
When the file is in the scratch folder next to the .hyperesources Folder being previewed. Any code that points to it will be able to be tested in preview in all browsers without any domain restrictions.

Ideally it would be good if we could do this with folders but I think you probably have most of the mechanisms already to do this with files.

Also when I have done this manually in the past I often have to quit hype to clear the cache for the file otherwise even when the file is not in the scratch folder after I will see a cached version (i know I can clear the browser cachebut iften do not want to)

Hope this helps to make sense ?

Another option would be to have an config option that allows to define a local folder and a server path:port on a project basis so people could spin up a local server and just preview it through that existing infrastructure. But that might produce issues with reflect etc.

If request by Mark isn’t implemented in Hype directly or is urgent one could establish a name convention like NAME_local.SUFFIX and have an exporterscript to sort these resources to a flat folder structure instead of the resource folder. That might just do the trick. See

Thanks. @MaxZieb

The only reason I would have a such a file in Hype would be to leverage hype’s server in preview.
The idea of being able to define a local folder in the same way is kind of what I am getting at here

One of the main points for me is to be able to use the normal Preview and not have to export.

For me at least I can do all of this manually but it would be good if I did not have to delve into the Scatch folder my self each time and deal with the caching.

but I think that may be a bit more tricky to do.

You should be able to define an exporter script to be used in the previews.

Thanks, Sorry it is a good idea and I have done something similar before but I did not always find it convenient and even though I can use exports scripts and write them not everyone is that familiar or has them.
Also having this built-in enables the sharing of the project without relying on an export script.

Didn’t argue against it… was a suggestion if this is an urgent need.

Yes, true. Would be nice if the export scripts could be bundled with Hype-Files. Also JS would be nicer then Python (because it avoids a new language and leverages the knowledge people build through Hype).

Hope Hype 4.1 adds folders and local preview files as you suggest

No problem, I did not think you had argued against it. :smiley:
We are both just clarifying

Tell me about it, I am not a fan of python. no brackets?? tabs and spacing are a pain in the…
( Without going too far off topic I have noted that other languages can be used so I will hopefully see what I can do in those for scripts I want to create. The key thing is to be able to get the hype json info I think and then deal with it in what ever language you need)

A post was split to a new topic: Using Javascript as a language for Export scripts

Btw have you given it a try with python…? Should be straight forward.

Yep… :smiley:

Thanks, I think I understand now. I would like the Resource Library to be able to be manually organized with folders and possibly be able to use folders/files alongside the .html file. However, I don’t think we will be adopting a way to have a folder structure and files only for preview. I think this case is limited by there being a good chance that the file a user needs to reach is either in a hierarchy outside of what Hype would serve, or is dynamic in nature and can’t be served by Hype’s static webserver.

I believe the best solution is to use the full URL and temporarily disable the browser security checking. It is a browser preference for development reasons like this.

Using an export script at preview time, as suggested in this thread, is another option. You could also have it be a regular resource, and just add a conditional to your code to use a different URL depending on if you are in the preview environment or not.

(Along side the export script, I’ll also mention that for assets specifically used by Hype, there is a notion of a “reference” URL (see is_reference in the docs) that allows you to give a full URL instead of a resource name for an asset. I would also like to expose this in the Hype UI.)

I guess I just felt I see a few people frustrated or take a while to work out that they have to use a server so was really asking for the gen pop rather than myself as I already have worked ways around for myself including both suggestions but thought it would be an easy thing to impement if we used the hype UI to add the files and since Hype already copies the files or alias to the scratch.
No worries, I can see where the gain for just preview alone is to low.

1 Like

An alternative that wasn’t addressed is an option to define your own preview folder and server url in the settings. This way one could export the preview to a local server that is running all kinds of other stuff (php etc.).

1 Like

I’ve also wanted to add a “Re-export” command that can be done with one keystroke and not show any dialogs - this could effectively let you export into your own server environment quickly and very generically solve the problem. Coupled with LiveReload or an AppleScript to watch the folder and open your own preview URL, it should be about as good!