I have a program allowing script files to "compete" with each other in a games such as Tic Tac Toe .
The visualization is made in the console and looks something like this:
| XO |
| OX O|
| X |
- X is the winner! Meh..
Not very exciting.
I was thinking of making a Swing visualisation, but after seeing a presentation on the Raphaël JavaScript vector graphics library I decided that I'd be cool to make the visualization browser based, even though every thing will be running on the same computer.
Do I need a full fledged web server to accommodate for this? How does the JavaScript communicate with the Java program?
Building a Swing interface would be the most straightforward solution, but this would probably be the messiest one as well.
The web browser solution is probably the most satisfying if you already have a web server going, but has a lot of overhead to set up and properly understand. Then again, you have layers of different technology to play with and get confused in (java, JSP, HTML, javascript, css, etc).
These days, with HTML5 and available javascript libraries, the web interface is in my opinion the best choice for most interfaces, so you might as well set up your machine and have it available for the next project.
Any communication between the server (Java) and the browser will take place with a HTTP request from the browser.
This may happen in two ways:
a) By pressing a submit button on a browser HTML page and rendering a HTML page on the server as a response (usually through server side scripting like JSP, although you could generate the entire page through java code)
b) By using Ajax in javascript to make an asynchronous call to the server, which will respond with data that you can then interpret and render with javascript (probably the best solution for what you are trying to do). There are many ready javascript libraries to help you with this, including jQuery.
In method b, you would essentially be waiting on the server side for a post from the browser and then you would be responding with a page written in XML, json or even pure text. Your javascript code would then interpret the data and render it on the browser HTML page (which you will have loaded at the starting point for the application).
Do I need a full fledged web server to accommodate for this? How does the JavaScript communicate with the Java program?
If you're going to host the JavaScript and display in a browser, then yes, the browser would need to be able to request the data from the Java via an HTTP request. Although browsers can load data via file:/// URIs, it's (quite) awkward to handle those requests dynamically.
It's trivial to install a web server, though. Tomcat is easy to install, and there are several other options if you prefer, such as TJWS (no relation), Winstone, LiteWebServer, Jetty...
If you're forced to run Java for the game engine I would suggest using Jetty to give you the ability to service HTTP request from a browser. It's all embeddd in your application and there's no faffing with having to package your app as a WAR and deploy it everytime you make a change.
[edit]
Just read about Tiny Java Web Sever which could also be an alternative to Jetty if you need a smaller footprint.
Javascript can communicate with a Java applet on the page (at least in theory). A Java applet is going to throw up a warning when it loads, and requires that Java be installed on the machine.
Yes a webserver will be necessary. Javascript will probably run as part of an html form. If any Java side processing is required, then web server is necessary. Since it is not possible for the html/javascript to communicate with a standalone java program. But Why need a java server side program at all? Can the logic not be written in java script totally?
Related
I want some way of creating a dedicated browser window for a browser (chrom-e/ium or firefox). Its content needs to be controlled by a java application (a http call to localhost or better a more direct way of communicating). These two should be bundled together in some way.
A little Background
I want to write a java desktop app but don't want to use Swing or javaFX for the UI. The UI should be written like a one page app and may be ported (at least partially) to the web. I have taken a look at the javafx WebView but would rather have a full fledged browser on my hands. It would also be nice to have a little more control over said browser to send files and read files in a more desktopish way. The only real requirement is that there has to be some java backend behind it and that is has to work offline.
Is something like this possible at all or is it just a pipe dream?
I am very almost a year late for the party, but:
There are a few (that I know) technologies that can help you:
Electron. It is basically what you want, you can use web
technologies to "forge" a desktop app, it's quite well known, I never used it but for what I have read that you can stick almost anything to it's "backend".
JavaFxWebView. There are some really nice ways to use it, you can
even use bootstrap and AngularJs, here is a example (not by me)
Yes it's possible and not all that unusual. Your app can open a default browser as described here -
https://stackoverflow.com/a/10967469/5087125
And then proceed to respond to http requests to your app.
Today I'm using an applet to modify client-side information, considering the new browsers i have to found out a new workaround to continue modifying file and execute windows command at client-side because some browser are suspending the applet execution.
Any ideia for solution that has allow windows command execution and access file at client side like Activex ?
Applets have always been sitting between webapps and desktop apps. In that sense, what you want to achieve is exactly what every hacker in the world wants to achieve, that is gain access to your computer from a browser. And I think it would fair to say that for that reason, applets are dying and are not coming back from the dead anytime soon.
But unfortunatly some functionalities need applets to run, and what you can do really depends on those functionalities.
Statu-quo
They are still working in IE (not Edge), Firefox and Safari. If you control your clients environment you can maybe still use them as is. But for how long ?
Move to Server
You move your functionalities on the server. In your case, it would probably mean upload files on the server, execute your commands there and send the file back on the client. Javascript and HTML 5 can certainly help here improve the overall user experience.
Move to Desktop
If you are doing some pretty intensive stuff on the client (processing multiple files, accessing resources that cannot be used from a browser, etc), you should consider regrouping this into a desktop app. You can even launch your app from a browser and sends some parameters to it by registering a Custom Protocol Handler, a la iTunes. Again, this is certainly not an easy replacement, as functionalities will often be spread out between the desktop app and the web app, which makes for some interesting scratch head moments trying to link the 2.
This is my first time working with Java and tomcat and I'm a little confused about how everything fits together - I've googled endlessly but can't seem to wrap my head around a few concepts.
I have completed a Java program that outputs bufferedImages. My goal is to eventually get these images to display on a webpage.
I'm having trouble understanding how my java file (.java) which is currently running in NetBeans interacts with a servlet and/or JSP.
Ideally, a servlet or JSP (not 100% clear on how either of those works. I mostly understand the syntax by looking at various examples, however) could get my output (the bufferedImages) when the program runs and the HTML file could somehow interact with whatever they are doing so that the images could be displayed on the webage. I'm not sure if this is possible. If anyone could suggest a general order of going about things, that would be awesome.
In every example/tutorial i find, no one uses .java files - there are .classes in the WEB-INF folder -- it doesn't seem like people are using full on java programs. However, I need my .java program to run so that I can retrieve the output and use it on the webapp.
Any general guidance would be greatly appreciated!
I think this kind of documentation is sadly lacking; too many think that an example is an explanation, and for all the wonderful things you can get out of an example, sometimes an explanation is not one of them. I'm going to attempt to explain some of the overall concepts you mentioned; they aren't going to help you solve your buffered image display problem directly, unfortunately.
Tomcat and other programs like it are "web servers"; these are programs that accept internet connections from other computers and return information in a particular format. When you enter a "www" address in a browser, the string in that address eventually ends up (as a "request") at a web server, which then returns you a web page (also called a "response"). Tomcat, Apache, Jetty, JBoss, and WebSphere are all similar programs that do this sort of thing. In the original form of the world-wide-web, the request string represented a file on the server machine, and the web server's job was to return that (html) file for display in the browser.
A Servlet is a kind of java program that runs on some web servers. The servlet itself is a java class with methods defined by the javax.servlet.Servlet interface. In webservers that handle servlets, someone familiar with the configuration files can instruct the web server program to accept certain requests and, instead of returning an HTML file (or whatever) from the server, to instead execute the servlet code. A servlet, by its nature, returns content itself - think of a program that outputs HTML and you're on the right track.
But it turns out to be a pain to output complete HTML from a program -- there's a tedious amount of HTML that doesn't have much to do with the "heavy lifting" for which you need a programming language of some sort. You have to have Java (or some language) to make database inquiries, filter results, etc., but you don't really need Java to put in the and the hundreds of other tags that a modern web page needs.
So a JavaServerPage (JSP) is a special kind of hybrid, a combination of HTML and things related to servlets. You CAN put java code directly in a JSP file, but it is usually considered better to use html-like 'tags' which are then interpreted by a "JSP compiler" and turned into a servlet. So the creator of the JSP page learns how to use these tags, which are (if correctly constructed) more logical for web page creators than the java programming language is, and in fact doesn't have to be a programmer at all. So a programmer, working with this content-oriented person, creates tags for the page to use to describe how it wants its page to look, then the programmer does the programming and the content-person creates the web pages with it.
For your specific problem, we'll need more detail to help you. Do you envision this program running and using some information provided by the user as part of his request to generate the images? Or are the images generated once and now you just need to display them? I think that's a topic for another question, actually.
This ought to be enough to get you started. I would now suggest the wikipedia articles on these things to get more details, and good luck getting your head around the concepts. I hope this has helped.
This addendum provided after a comment you made about wanting to do a slideshow.
An important web programming concept is the client-server and request-response nature of it. In the traditional, non-Javascript web environment, the client (read browser) sends a request to the server, and the server sends back bytes. There is no ongoing connection between the two computers after the stream of bytes finishes, and there are restrictions on how long that stream of bytes can continue. Additionally, outside of this request and response, the server usually has no capability to send anything to the client unless the client requests it; the client 'drives' the exchange of data.
So a 'slideshow', for instance, where the server periodically sends bytes representing an additional image, is not the way HTML works (or was meant to work). You could do one under the user's control: the user presses a button for each next picture, the browser sends a request for the next picture and it appears in the place where the previous one was. That fits the request-response paradigm.
Now, the effect of an automatic slideshow is possible using Javascript. Javascript, based on Java but otherwise unrelated, is a scripting language; it is part of an HTML page, is downloaded with the page to the browser, and it runs in the browser's environment (as opposed to a JSP/servlet, which executes on the server). You can write a timer in Javascript, and it can wait N seconds and send another request to the server (for another picture or whatever). Javascript has its own rules, etc., but even so I think it a good idea to keep in mind that you aren't just doing HTML any more.
If a slideshow is what you are after, then you don't need JSP at all. You can create an HTML page with places for the picture being displayed, labels and text and etc., buttons for stopping the slideshow and so forth, in HTML, and Javascript for requesting additional pictures.
You COULD use JSP to create the page, and it might help you depending on how complex the page is, but it isn't going to help you with an essential function: getting the next picture for the slideshow. When the browser requests a JSP page:
the request goes to the server,
the server determines the page you want and that it is a JSP page,
the server compiles that page to a servlet if it hasn't already,
the servlet runs, producing HTML output according to the tags now compiled into Java,
the server returns HTML to the browser.
Then the server is done, and more bytes won't go to the browser until another request is made.
Again, I hope this has helped. Your example of a slideshow has revealed some basic concepts that need to be understood about web programming, servers, HTML, JSPs, and Javascript, and I wish you luck on your journey through them all. And if you come to think of it all as a bit more convoluted than it seems it needed to be, well, you won't be the first.
You can create a JSP that invokes a method in your Java class to retrieve the BufferedImage. Then you must set the content type to the adequate image type:
response.setContentType()
The tricky part is that you must print the image from the JSP, so you have to call:
response.getOutputStream()
from your JSP, and with that OutputStream you must pass the bytes of your BufferedImage.
Note that in that JSP you'll not be able to print out HTML, only the image.
I'm not sure where you need more clarification, as it seems you're a bit confused about the concepts.
BTW.: A JSP is just a servlet that has an easier syntax to write HTML and Java code together.
I am working on an application in Linux which will interfaces with hardware. One of the requirements is to create the GUI in Web-browser . the application will be c++ based. I m not familiar with web realted stuff so i want to know Is it possible to do such a thing (currently it's a console application take input from txt file/cmd line). gui will be simple using button and showing output messages on browser from the application. i want to know which technologies/languages are involved and how can it be done. some of the idea i read but havn't found anything concrete yet. if u have any idea about these or a better suggestion please share
run the app in background and communicate with browser ?
call library functions directly from browser ?
any other idea ?
I would start by setting up a regular HTTP server, like lighttp or Apache httpd.
You say you already have a command line program that does the actual work - As a first step, I would reuse that, and configure the web server to call your program using CGI - see forexample http://httpd.apache.org/docs/2.2/howto/cgi.html for apache
Finally, I'd pick some javascript framework like jQuery or YUI with Ajax capabilities to do requests to the server to call the CGI script from within a webpage. You could also create a form-based web application without ajax or any framework, but that would require you to stuff all kinds of logic in your program to generate HTML pages. By using Ajax, you can leave the command line application as is, and parse any responses it gives with javascript, and then use that to dynamically change the webpage in a way that would make sense to the user.
If this all works, then I would try to figure out how to package all these components. Perhaps you just want to create a simple archive with all the programs inside, or maybe you want to go as far as actually embedding the webserver in your program. Alternatively, you may want to do it the other way around and rewrite your program as an ISAPI module that you can plug into your webserver. Or if that's not integrated enough still you could write your own (partial) HTTP server. That's really up to you (I'd probably spend time and energy on searching for the leanest, meanest existing open source http serverr and use that instead)
At any rate, the prior steps won't be lost work. Most likely, developing the web page is going form a substantial part of the work, so I would probably create a quick and dirty working solution first using the age-old CGI trick, and then develop the webpage to my satisfaction. At that point you can already have an acceptable distributable solution by simply putting all programs in a single archive (of course you would have to tweak the webserver's configuration too, like changing the default port so it won't interfere with existing webservers.) Only after that I would spend time on creating a more integrated fancy solution.
I ended up using Wt though I'd update for future reference.
These are how I thought of doing this, in order of complexity for me:
Create a simple server-side-language (PHP/Python) website that can communicate with (ie launch and process the return of) your application
Modify your application to have a built-in webserver that just punched out HTML (command line parameters taken through the URL)
Modify the app to publish JSON and use javascript on a simple HTML page to pull it in.
You could write a Java applet (as you've tagged this thread) but I think you'd be wasting time. This can be quite simple if you're willing to spend 10 minutes looking up a few simple commands.
After 12 years, web browser-based GUI started to appear, WebUI is one of them.
sorry in the past I have not been able to formulate my question coherently. This will be my last try. =|
Basically, I want to do something like this website is doing: http://www.ninjavideo.net/video/56388. They are rendering an iframe that points to a port on localhost. You will see nothing in the iframe if you dont have their applet running (which can be found here: ninjavideo.net/applet.php ). I want to write a script that does something like what applet.php is doing, but I don't think they are using only php code as it won't run on computers that don't have php installed. Do you suppose they are using Java/C to do this?
Thanks for all your suggestions.
An Applet is basically a piece of Java code which is served by a webpage and is supposed to run at the client machine. You can learn more about Applets at Sun's own Applet tutorial. If you're green to Java as well, then I recommend to go through Trials Covering the Basics first. Opening sockets (ports) using Java code is covered here.
That PHP script is just serving the applet code from the server, so that the client can download it.
You could do this in PHP using a ready-to-run Apache setup (there are some that are ready to run from a USB key, should be possible to make into something that a client can install, but is complicated, see e.g. this tutorial) or a product like NuSphere Dock:
PhpDock is a deployment platform for PHP applications.
PhpDock enables you to deploy any PHP web application as a Stand Alone Windows Desktop application w/o any changes in the code.
PhpDock combines NuSphere's powerful embeded Srv webserver and browser components.
I would usually say that if you are looking to build a Windows application, you should go with a tool that is aimed at just that, i.e. C++, C#, Java, the .NET platform, Delphi, and the likes. But if you need some kind of daemon or local web server, you may actually be well off with a product bringing a web server to the desktop.