There is a way to deploying java applications within fat-jar. You compile and build all the files and put into single file, your backend with REST api and frontend - javascript files. As a server you use embedded one - jetty, tomcat, scalatra etc. How does (and where) operating system cache the content of jar file while running java -jar? (I'm interested mostly in ubuntu and centos) I ask in context of serving that javascript file to the client. [In worst imaginable case the system might extract the whole jar file each time the http request comes, that would be horrible]
Related
I have a web project that I made with HTML-Javascript. I want to use the XML file (in local project folders) in this web project in javascript. Then I want to make a few changes in this XML file and overwrite the same xml file again. How can I do that?
JavaScript runs in the browser and is isolated from the local system. So the usual way is to upload/download the file. However here are several possibilities.
A small server application
Develop and start a small server application for example with node.js. The server part will provide the file system access.
Use a wrapper
A more advanced version of the previous solution, you encapsulate the web application using a wrapper like Electron.
File System Access API
Use the File System Access API available in some of the new Chromium based browsers.
I am looking a functionality like follows for a web application,
User select a local folder with high resolution images.
Resize this images and send to server for processing.
Make folders in the local file system and copy the original high resolution images according to the server response
Can we achieve this without using any locally installed application but with a web application only. Please guide me, which method/technology can I start with.
Browsers will not allow to access local file system due to security reasons. Image any website able to play with local files. Browser provides sandbox where your js app can run.
You best options could be to use webstorage. You have limited capacity there though and it is not accessible directly to user. Different browsers can be varying implementations.
You can do this with node.js and sharp or Imagemagick.
As others have mentioned in browser Javascript cannot access a local file system for security reasons. So you'd have to provide an upload interface to upload the image to a node server first, then you can convert the image into a buffer/data stream resize the buffer and save it again on the server ready to be downloaded.
NodeJs is a Javascript runtime
https://nodejs.org/en/
Express is a application framework you can build a webserver that can execute your javascript
https://expressjs.com/
(You've already said you'd prefer not to but) You could build it as an node desktop application using electron which would have access to the filesystem, but it would be a self contained app not a in browser application.
https://electronjs.org/
Sharp and imagemagick plugins are the most popular nodejs based image processors
https://www.npmjs.com/package/sharp
https://www.npmjs.com/package/imagemagick
Hope this helps you get started
I ran into a dilemma lately as I was exploring the various plugins for gulp. One of them was gulp-gzip and till then, I have never thought about compressing my files. I got gulp-gzip to work correctly and spit out gzipped versions of my HTML, CSS and JS files but then, what next?
I googled around and found that most articles talk about configuring the server to send gzipped versions of the content automatically to the client upon request. But then, I kind of don't seem to understand the purpose of gzipping locally.
So, my questions are:
Can I serve gzipped content I get from gulp-gzip without configuring my server?
If yes, how should I proceed -- what should I name my gzipped files as? Should I keep the .gz extension and link to my CSS and JS files using the same?
If yes, can I test it locally by linking to the same .gz files?
If no, what is the purpose of gulp-gzip in a development environment if the server can be configured to do it automatically?
Most servers have an option to serve statically pre-compressed files if a *.gz version exists, i.e. when user requests foo.css, the server will check if foo.css.gz exists and use it.
It requires server support (the server has to set appropriate HTTP headers), so it won't work with the file:// protocol and may not work on every server.
In URLs you have to refer to the base filename (do not link to .gz directly).
Compressing files ahead of time may be better:
You can use higher compression level (e.g. maximum gzip level or the Zopfli compressor), which would be too slow to do real-time on the server.
Compressing ahead of time saves CPU time of the server, because it doesn't have to dynamically compress files when they're requested.
Just be careful when you deploy files to the server to update both *.css and *.css.gz at the same time, otherwise you may be surprised that you sometimes see old version of the file.
Backstory:
I am creating a development tool for web development. This tool loads a users webpage into an iframe, this allows the program to resize the iframe and simulate mobile screen sizes. I also want to build in a tool that automatically refreshes the iframe when local content is changed. To do this I am going to use Ajax to load files in and every 5 seconds or so compare the file to its previous version from 5 seconds ago. I currently have it working with just one file.
Question:
Is there a way to get all the files in a directory with Ajax. The little javascript same origin rule does not apply because the user is running this tool locally from the same directory as the project, no files from a server are being pulled.
Javascript which runs on the client machine can't access the local disk file system due to security restrictions.
If you want to access the client's disk file system then look into an embedded client application which you serve up from your webpage, like an Applet, Silverlight or something like that. If you like to access the server's disk file system, then look for the solution in the server side corner using a server side programming language like Java, PHP, etc, whatever your webserver is currently using/supporting.
WaveMaker is a powerful ajax based UI builder, but its JSON-RPC API standard is incompatible with our web service, which only has a RESTful API. As a result, we would like to design an UI without using any service using WaveMaker, and only extract part of its source code that runs on browser side (discarding all services)
Unfortunately, we can neither view or test the extracted code (all .html files show an empty page), a javascript reference in index.html is pointing to runtimeLoader.js, which we cannot find anywhere. So, is it possible to deploy the browser side code on a web container (not an application container like Tomcat) without runtimeLoader.js? If this is not possible, how do I change the source code so it can be tested without using WaveMaker?
If you don't mind having a java server in the mix, you could "import" REST calls to your API into the application. The XHR service (new in 6.5) targets JSON returning services. The 'Build-a-Service' does best with XML returning services. The browser would then call the WM java server, which in turn calls your REST services.
An easy way to get started with a WaveMaker client only app is to use the phonegap build option. This will build a zip file of a stand alone app. If you unzip that into say an apache served folder, you will render pages, etc. Note this build is targeted towards mobile devices via phonegap, so you will want to make adjustments if you are targeting desktop browsers.
Also, runtimeLoader.js can be found in the client runtime lib folder. e.g. /studio/lib/runtimeLoader.js of the installation.