I'm trying to decide whether to use GWT or manually-written JavaScript. If I use regular JavaScript, the Java app works like this:
The client accesses a URL, and the server executes a servlet.
The servlet queries a database and forwards the data to a JSP.
The JavaScript in the JSP displays the data in a table.
From what I've read, the process changes when you use GWT:
The client accesses a URL, and the server provides a page with GWT-generated JavaScript.
The generated JavaScript creates a table and uses GWT-RPC to tell a servlet to provide data.
The servlet queries a database and returns the data to the JavaScript, which displays the data in a table.
In the second process, the client accesses the server twice: once to access the URL and once to tell the servlet to provide data. I understand that the second part is performed asynchronously, but it still seems very inefficient. I'm sure I'm missing something fundamental, and I hope someone will set me straight.
OK, let look at this in terms of efficiency.
Yes for the simple case you describe, the client may have to wait slightly longer.
In terms of developing a useful site though, you most likely will be doing authentication and wanting to make ajax calls from the middle of your page. You too may want to do layout changes based on user input that are impractical and messy to do in a jsp page.
Manually written javascript used to run quite differently in different browsers too, and that was a nice thing about GWT compiling different versions for particular browsers. It may not be as true today but you should consider browser differences if you need to target more than one.
So my answer in terms of efficiency is that no GWT is not the most efficient for the simplest cases, but if you need to make a more complex web-application and want to avoid browser issues, then developing in Java is easier and simpler to maintain.
I actually am returning a .jsp page on my first call, and then the GWT javascript get bootstrapped from there (instead of using an html page). There isn't any real reason you couldn't include whatever data you wanted with the jsp page, except that if your requirement is so simple, keep it that way as for sure there will be some cost in bootstrapping the GWT code. In my case, I need to do authentication first, and then data than gets returned depends on their credentials, and then a load of ajax calls depending on what the information the user needs. Developing in javascript by hand would be a nightmare.
GWT compiler generated java script is cached on the client side so when you access application for the first time you will see that it takes some time as compared to plain java script. But if you try to access it again you will not see the performance issue in loading the page.
In both cases you are accessing the server twice. First request is to load the view and second request is to get the data from the server.
GWT is not suitable for simple application. It is mainly used for enterprise applications.
GWT compiler generated java script handles most of the browser intricacies which is hard to maintain in plain java script code.
Related
The output HTML code is not complete, because the javascript in it is not executed.
Do I need to run the javascript somehow?
I want to get the content of a live-bidding website through java.
Rather than scraping the dynamic content, it would probably be more practical to figure out what the javascript is doing (e.g. what AJAX calls it is making) and code your application do the same thing.
You haven't mentioned which website you are talking about, but if they want you to do this kind of thing, it is likely that they will have developed a "web API" for people like you to use. And the flip-side is that they may not want people gaining an unfair advantage over other users by doing this kind of thing.
Either way, check the site's Terms of Service, etcetera ... or you might find yourself in legal trouble.
I am making a website which involves lot of computing at the back end...I'm using Java Script at the front end and Java for the back end. Could there be any security problems because of Java Script or can I use any better front end instead of Java Script to make website better?
The biggest potential security problem with Javascript has nothing to do with Javascript (and also applies for "dumb" websites): If you think that the end user will only use your "official" client code, and as a result blindly trust the Javascript code with security-relevant information, then you have a security problem.
You need to validate all data on the server. The user can make his browser send whatever data he wants, whenever he wants. He does not even have to use a browser (could be a completely hacked-together tool).
You must not put "secret" data into the client code. Even if it is not directly visible in the browser, the resourceful user can see it.
Could there be any security problems because of JavaScript
Not intrinsically. You could introduce security problems by writing insecure code, but that is try of any language.
can I use any better front end instead of JavaScript to make website better?
Other options for client-side programming require browser plugins (such as Flash) or specific browsers (such as IE for VBScript).
You might not need any client side programming, and any JS you do write should be progressive and unobtrusive.
I'm creating a Rails application and on it, there should be a Java Applet.
My question and problem is that the applet must be tightly integrated with the Rails parts. I must be able to get a list of all users, update an image, etc... And there's a surprisingly small amount of information available on the Internet of how to use applets with Rails. So please give me some hints. What is the best way to do it?
Send parameters to the applet?
Use Rails REST interface from the applet?
Use JRuby somehow?
Other....?
Thanks!
Can you provide more details? In the meantime, here's my take on your questions:
Send parameters to the applet?
Your rails app will be able to serve the applet, but once served I don think you'll be able to send messages to it (however you will be able to respond to messages from it, which is perhaps what your asking).
Use Rails REST interface from the applet?
You've kind of answered that one yourself. REST is an interface design and therefore can be accessed from anything that can issue a HTTP request. The trick is to correctly construct the URL so rails knows what you want to do. There's good info on configuring rails routes (REST and non-REST) here http://guides.rubyonrails.org/routing.html
Use JRuby somehow?
You could use jruby for this, but you dont need to. Your server (rails) and your client (browser/applet) talk to eachother via http and so don't need to be the same language or run on the same VM.
Hope that help....
I think the reason you probably haven't found anything specific about Applets and Rails is that they function a bit at different levels and aren't really dependent on one another. It looks like Rob was trying to clarify a few things, so I'll take it another step just to be sure we are all on the same page.
The job of Rails is to generate and serve up HTML/XML/Javascript/images via a web server to the user's web browser for rendering. Part of that HTML will be an APPLET (or possibly OBJECT) tag, which instructs the browser to load the applet. Usually, this instructs the browser to invoke the Java Plug-in and lets it handle loading the applet. Once loaded and running, however, even though the applet is displayed on the current web page in the browser (or maybe in another window even), it really isn't terribly aware of the web page it is sitting in. For the most part, applets don't care about the browser or the page they are "part of". So if an applet needs more information, or needs to ask for data, it usually will just send an HTTP request to the server it came from. It would then parse the data and update itself.
I am assuming what you probably need is for something to be clicked or entered into the applet, and that data be used to update the web page that Rails is serving to the browser. With an applet, you pretty much have 2 options:
Use the web server application to share state information
Use the Java-to-Javascript communication using JSObject as indicated at http://java.sun.com/products/plugin/1.3/docs/jsobject.html
Honestly, option number 2 comes with so many caveats, that I would never use it unless you had complete control over browser and Java versions on all potential users' systems. Even then, I'd be concerned of an update to something breaking it.
Basically, option number 1 leaves you with the Applet and the Javascript/HTML polling the web server (Rails) periodically to see if there are any updates or requests that they need to respond to for data exchange. If the applet is updated by the user, it sends a message to the web server via a URL request/post and the next query (probably via an AJAX-like call) by the web page will see the new data and the web page will be updated with it.
I hope that helps.
Two really great answers. I appreciate them a lot, thanks!
Reading your posts made me realize that the best choice is to use HTTP-requests to Rails REST interface. However, I see some downsides with this approach. But I don't see any better solution to it. One feature the applet should have, is to be able to browse and search in all products, which can be quite many. Sending a HTTP-request for each search will be expensive. Maybe I could solve this by loading all products when the applet starts. Then the browsing and searching would be fast. Or maybe do some nice caching. So once they are found, I don't fetch them again.
About not finding lots of information about this on the net. I see your point monceaux. But... I still think that there should be more. I mean, in my situation I would really like a Rails specific library that helped me send requests to correct urls. To bad Java is not that dynamic though. Kind of hard to do some stuff automatically, like in Ruby and Rails. Maybe I'll write a small library for this. I mean, I must write it anyway. So why not make a library of it? Some people might have use of it.
Why is it not advisable to use JavaScript in JSP? One rationale that I can think of is turning off the feature in browser would stop the code from executing. Is there any other reason behind this?
Afaik, there is no problem in using javascript in jsp, and many sites do use it. Especially if your site is a web app, you will have to use both side by side. They are completely independent. You just have to make sure that what you are using each for is appropriate.
As for the part about turning off javascript in a browser making the site unusable, it is true whenever you use javascript, with or without jsp.
I know this is a very old question but I thought I would pipe in anyways. I think you should use javascript in this current time period as it allows for a very rich user experience and with js libraries like jQuery (my personal favorite), prototype and mootools it has become very easy to integrate javascript into your application with little effort.
If you design your application right, you can add javascript that enriches the user's experience (and can make it easier for them to use your site/application) without additional server overhead and very little effort.
How ever - your site should not rely on the javascript for function as the user's browser may not support it.
Javascript should be unobtrusive and provide a richer experience to those user's who support it.
Here is a good article about UI and upgrading gracefully instead of designing for the failure of the user's browser. http://realtech.burningbird.net/javascript/accessibility/gracefully-upgrading
He's got to mean "don't use java scriptlets", which is the stuff between <% %>.
The biggest reason has got to be maintainability and debugging; scriptlets make everything make both very difficult.
On the other hand, if you implement taglibs, you can extract any logic to a real java class, which is easily debugged, and you will still be able to open things up in a visual xml/html editor, since taglibs are a valid xml structure.
Now, it is a bad idea to do validation on the client side (in javascript). Users can disable javascript or even access a url directly to get around validation, which opens you up to exploits.
If you have many clients, then it may be a good idea to put calculations on the clients with JavaScript. If you do everything on the server, you are just going to waste the many processing powers provided by the client's browsers, and the speed advantage of Java would be for naught if too many clients make the server busy. (Thanks to #Subtenante in the comments for pointing this out!).
But on the other side, Java running on the server is faster than JavaScript on the client, and it won't suffer from redundant code on the client, for testing which browser the client runs.
JavaScript has its uses as trex pointed out, though. Since it runs on the client, it can for example validate form fields before sending it to the server.
JSP is a server side technology. That is - Server parses/compiles all the information and then sends it to the client (i.e. your browser). And then..
If received data contains ANY javascript then browser interprets it in its own javascript VM and server is long forgotten by then since HTTP is stateless protocol.
Considering "not recommending JS in web" I wouldn't bother about it. Most of the sites use JS extensively thus turning it off on the client side would render them mostly useless.
I have written a standalone Java application that I've packaged into a jar file that takes in some command line arguments, does some hardcore computations, and then writes out the result to a file along with some output to the default output stream pointing to where the file with the results are.
I now want to create a website around this technology. The idea is that the user can fill in an html form, post it to a webpage, which would then call the Java application, parse the results from the Java app, and display it to the user.
Currently, I am using a little bit of PHP to collect the data from the post request, and then just using an exec call: java -jar -Xmx128m myapplication.jar command-line-arguments
Is this bad?
I do have several thousand visits to my website each day and each execution of the Java application can take upwards of 30 seconds to a minute, so I don't want to be overly inefficient. It seems like there would be a better solution than having to call Java directly for every request.
I keep hearing things like java servlets, beans, tomcat, glassfish, etc., but I don't understand what they are and how they would benefit me. What do these get me? Faster results because the Java JVM doesn't have to be created each time I run the application? Less memory usage? I obviously want it to run as fast as possible with as little memory footprint as possible.
So, what is the best approach that I can take here? I don't want to do any serious rewriting of my application as there is a lot of code (so rewriting it to C or C++ is out of the question).
Thanks.
Ok, servlets are smalish applications that are designed to run inside of a container. They provide an extension point for you to insert your java code into either a simple servlet container like tomcat, or a more fully featured application server like glassfish. You want to do this because the application server does the heavy lifting of dealing with the http interaction and provides other features like security, logging, session management, error handling, and more (see the servlet specification).
When you make your application live within an application conatiner (web server with all those other extra features), you can also manage the lifecycle of your application better. You'll be able to start and stop the application without shutting down the web server, redeploy, start more instances, etc. Plus, when you come up with that great second application, its easy to drop it in right next to the first one. Or, you can cluster several machines together for easy redundancy and load balancing, features of the application server.
This is just a start, there are many more features, technologies, and frameworks out there to help you make container based applications. Servlet tutorial.
[Do these get me] "Faster results because the Java JVM doesn't have to be created each time I run the application?"
Yes.
And -- bonus -- you can replace PHP so your entire site is in a single language: Java.
Further, you can consider revising your use cases so it isn't a painful 30-60 seconds in one shot, but perhaps a series of quicker steps executed interactively with the user.
Run your code inside a servlet container.
Assuming that you need to keep your website in PHP and as you already have java installed on your machine, simply install a free servlet container (such as Apache Tomcat, or Jetty). Configure to run the servlet container on an unused port. (8080) is their default.
These servlet containers are really java based webservers, just like Apache, however specialized in serving java code.
The most obvious advantage of using a java webserver rather than a new java.exe invocation for each request, is that your java virtual machine (jvm) will always be "hot", up and running. Each new start of the java.exe (jvm) will give you those extra seconds of waste.
The second advantage of using a servlet container, is that the container will enable your code to run in a new thread, inside the jvm, for each new request. You will have no problem providing your service to your thousands of users a day. Most likely, your machine will crash if you were to start hundreds of java instances rather than one.
Place your code inside a servlet. It really is easy even for a newcomer. You will talk to the servlet via HTTP (doGet or doPost methods of the servlet). Pass the php request form to this servlet and have the servlet give you back whatever: a page, a json object, xml or plain text.
You probably don't want to invoke the java app directly from the website. Like you said, if the java process takes 30 seconds to run, your web server is going to get way bogged down, especially if your site is getting pounded.
You may want to look into web-services (and possibly a message queue) for dispatching back-end processing requests. The PHP page could call the web-service on the server, which could then put a processing request on a queue, or just kick off the java app in an asynchronous fashion. You don't want the HTTP request to wait for the java app to finish, because, while it's processing, the user will just have a hung browser, and the HTTP request might timeout.
Once the java app finishes, it could update a database table, which the user could then access from the website.
The easiest thing to start with would be to embed a webserver in you application. Have a look at Jetty.