Trying out Whisk, and totally loving it so far. So fairly priced, too! We’ve been using a cloud-based solution for instant HTML rendering, but this of course is so much better. I especially appreciate the scroll sync. (Thanks for developing yet another awesome app, @jonathan!)
I have run into what I imagine is a newbie issue: I’m calling a JavaScript file, that I handily also have open in Whisk <script src="/Users/myname/Desktop/test.js"></script>
But it’s failing to load, with a 404 (not found) error for the address: http://127.0.0.1:49409/Users/myname/Desktop/test.js
How should I be referencing the file? Or is there a permission I might need to set somewhere?
This is now working. In case this is helpful to anyone else:
The first obvious thing is to keep the HTML file and the JavaScript file in the same folder, so the script call becomes <script src="test.js"></script> But: that’s where I started yesterday, and it led to the initial 404 (not found) error. Then as part of troubleshooting I included more of the path name, as shown my original post above. But that was wrong: the JS file must be in the same folder (or subfolder) as the HTML file. (As I said initially, in some ways still a newbie to JS.)
The other difference is that I changed the setting in Safari > Develop menu > Disable Local File Restrictions, checking that to allow local files. I’m pretty sure that made the difference. What’s weird is that I now can’t recreate the error: I’ve turned that back off, and the file still loads. Puzzling, and I include the information here in case it makes the difference to someone else who hits this issue.
I’m glad you were able to solve it; I’ll have to think about this a little bit because it is conceivable it could be fixed in Whisk. Full mac file system path URLs though are a bit unusual to use though since they won’t exist on other users’ machines.
The few things to keep in mind are:
If the file is not saved to disk in whisk, it will not serve anything from the filesystem.
You can always use relative path addressing to the .html file you are working with (once saved)
Whisk uses an HTTP server and does not use file:/// URLs. There’s no setting in Whisk to “Disable Local File Restrictions” so a file:/// URL won’t be able to be used in the app. I actually tried testing with a file:/// URL in Safari and couldn’t get it to display from a HTTP page, so I’m not sure what that button even does but I suspect I just hit some sort of bug.
If you are using the Mac App Store version of Whisk, you must make sure to give correct access first.
If you are on Catalina and trying to access the Desktop from Whisk, at some point the system will prompt for access:
I’m not sure if this is related or not, but the web site I tried Whisk on has a sidebar showing on all the pages, for that reason resources in it have an absolute file path, meaning their url starts with a ‘/’. Whisk can’t resolve those apparently, so the css file and images (logo, etc.) aren’t rendered.
It sounds like you have a notion of a “server root” somewhere on your disk, and one that isn’t the root of your filesystem?
There’s not an option to set this right now, but it is a good feature request! Brainstorming out loud, I could see this being possible to setup in the File Inspector… yet I assume you’d want it to be sticky for any files that are edited in that particular tree, but not others, so perhaps it is in part a global setting.
I’m not sure what you mean, the files on my Mac aren’t at the root level. I upload them to a server where the notion of root is, for sure, different than on my local machine.
I mean to say that you probably have a local mirror as to what is on the server. For example, with the Tumult site, it looks on my computer something like:
If I was editing the hype or whisk index.html pages, I might have code that uses a /css/style.css or /js/jquery.js absolute URL. In this case it’d be great to define /Users/jonathan/Sites/TumultWeb/ as a “root” when previewing. From then, whenever I open any files within that root folder it will know that absolute URLs should be based on it.
Does that sound like it would resolve your workflow?
