I can not figure out how to make nuxt generate fully static website. It makes api call static and that is awesome. But all images, and download links still making request to a remote server.
Is it possible to generate fully static website where all links to external files(<img src="remote.jpg">, <a href="remote.pdf", background-image: url('remote.jpg')) will be downloaded and placed in local folder and then every url will be replaced to local files? Or nuxt does SSG only for APIs?
You could totally optimize and put all of your assets into the /static directory indeed.
It will require some CI or any kind of build step to have them properly updated, organized etc but nothing impossible (this will keep everything in the same place). Meanwhile, having resources outside of your server is not bad in the principle itself neither.
Related
I want to host the Swagger UI behind the same webserver our API is running on (at least on dev and staging). Is it possible to do that without having to use Node whatsoever? I feel that it should be possible to host the static HTML, CSS and JS files but I can't see how.
This page* on Github suggests that swagger-ui-dist is designed for this scenario but the related page** doesn't really explain how to implement it but seems to show that Node is still required anyway.
I find the docs quite confusing.
*https://github.com/swagger-api/swagger-ui
**https://www.npmjs.com/package/swagger-ui-dist
I just worked it out. All the static files I require are in the dist directory.
I have a WebCenter Sites installation. Separately, I have site.js and site.css files. How can I make a WebCenter Sites template use these two files? Where do i put those files so they can be consumed?
What I've done so far is set up a simple HTTP server outside of WebCenter Sites and used <link> and <script> tags to point to those files on the external server. This does indeed work, but I prefer having the files served from the sites application.
I see sites exposes a CSS type asset, but it seems to be tied to their widget framework. I was thinking to just make an empty widget with CSS, then I could reference the widget/asset in the <link href=. Again there aren't many examples of this online.
Can anyone give me some ideas on how to serve files from within WebCenter Sites?
There are alternatives to storing files directly in the webapp, such as using a custom basic assettype to contain the files, and then delivering them via blobserver (or just rendering inline). The advantage to this is that you are managing assets to keep environments in sync, rather than updating the webapp & redeploying.
The path needs to be relative to the web application context. There are probably better ways to reference it in Sites, but the lowest-common denominator approach that will work for all J2EE web applications is to use pageContext.request.contextPath, so the link would look like:
href="${pageContext.request.contextPath}/src/stylesheets/css/styles.css"
So if this were used with a JSK, the src folder would be under [JSK_HOME]\App_Server\apache-tomcat-7.0.42\Sites\webapps\cs
I am working on application that loads about same 10 js on each page. This makes the website performance too slow. Is there a way I can changes the configuration in Apache, so that I can have all my js loaded in Cache on the home page itself.
No, each resource - images, css, js, etc. - is loaded by Apache individually.
The way around this is to minify (compress) your JS into one file using a tool. But, you'll have to rewrite your HTML pages to point to the new compressed file.
Folks:
I'm creating an app using Node Webkit. The purpose of this app is to display images and pdfs. The app needs to download those files from a central repository, and cache them locally. When the app runs offline, the files should still be available, and displayed.
On the face of it, this sounds like appcache is the answer - and that indeed is where I was heading when this was a pure webapp in a browser. However, now I've discovered node-webkit, and here we are.
node-webkit's GitHub wiki states:
"However, application cache is designed for browser use, for apps using node-webkit, it's less useful than the other two method, read HTML5 Application Cache if you want to use it."
But doesn't say why.
I've also researched node.js filesystem - but that seems like a whole magnitude of complexity above what I need.
Can anyone point me in a sensible direction?
Thanks.
It has to do with the nature of App Cache itself.
You specify a manifest file that lists all the static assets required for your app to run offline. You don't have any programmatic access to the cache to add and remove files via JS.
So for a node-webkit app, it'd make more sense to fetch these files and store them in the Application Support folder (Or AppData, depending on the platform). That's where the node.js part is really useful, the file IO stuff.
Im building an AIR application using the HTML/JS SDK.
I can include scripts and stylesheets as long as they are in the same folder as my website, but no remote content fetched from the Internet can be included ! No remote scripts, neither from jquery nor from google... I put <script type="text/javascript" src="http://pagead2.googlesyndication.com/pagead/show_ads.js"> and nothing happens ! It is the case for every file, not only this one.
Have you ever run into this issue ? In the AIR documentation they seem to present us with big mashups and remote inclusions all the time, still it won't work for me !
You can definitely do this in AIR, but you need to work around the security restrictions as by default you can't do this from the first frame that is loaded. Thankfully it's not too hard.
You need to create an iframe in your main html page (e.g. index.html) and load all of your content into this. Your main html page then acts as a controller of sorts allowing you to call methods which require enhanced security permissions (file system etc..), while any code loaded into the iframe is allowed to load external media and scripts and also allowed to use JavaScript eval and other methods which are otherwise blocked in the main frame of the application.
You can read about it here http://help.adobe.com/en_US/AIR/1.5/devappshtml/WS5b3ccc516d4fbf351e63e3d118666ade46-7f08.html#WS5b3ccc516d4fbf351e63e3d118666ade46-7f07
Read the full page so you understand the concept, but pay particular attention to the sandboxRoot and documentRoot attributes when you are setting up the iframe.