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.
Related
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.
I've just started programming with Java, so might appear as silly question, but I was not able to find simple answer on the internet. This is "big" question which I have to answer before getting too deep into development, so you can help me to save a lot of time on trying different approaches.
I am currently creating a website using Java. Important feature of this website would be realized through separate Java thread (like daemon) which must be run in background for as long as the user is on the website. At the sametime, website applets must have means of communication with this thread.
I see three potential solutions to this:
Create traditional multipage website with stand-alone java applets in each separate page. I am not sure if it is possible, the following questions arise:
is it possible for java thread created by java applet to continue execution after user navigated to another webpage (on the same website)? I assume that yes.
is it possible for newly launched java applet to communicate with java thread already running in background? (I've seen part of documentation covering communication between java applets through JavaScript, not sure that this can be used in my case. Any other options?)
Create single-page website, with one single java applet, responsible for all navigation and rendering all pages. This solves the problem with background daemon, which becomes easy to implement and communicate with, as part of single applet, but raises one more questions:
I know that applet can modify current webpage. Is it feasible to use this feature to simulate navigation between different pages?
Create Java Webstart application, basically by taking the single java applet from p.2 and converting it into stand alone application.
I want the whole thing to have a look and feel of website, so I would prefer option 3 over option 2 and option 1 over option 2.
Thank you for any thoughts you share.
UPDATE:
Does anybody know answers specifically to the two questions under p1? If it is possible to work with java threads the way described?
Now I would most probably opt for making a Java Webstart Application. This should be the least painful way.
UPDATE 2:
I finally decided to work on single java applet, which can be easily converted to JWS application if needed. Nature of my project is that I need to make impression of working with website, that's why I am putting additional efforts to make it appear as a website. For knowledgeable people it will be obvious, that it is more like a local application.
Solution I chose has following benefits in my situation:
- easily convertable from JWS application to Java applet and back.
- no problems with running background thread and communicating with it.
- more reliable security (meaning that I don't need to use any mechanisms to pass over session ids from one applet to the other)
Contras:
- if size gets large, start up will be slow - I hope to avoid this.
- Security issues - I tried signing the applet and it helped a lot.
- Work of navigation buttons in browser (back and forth) - I hope to be able to replicated it in applet. Think applet should be able to catch this event.
Java thread [...] which must be run in background for as long as the user is on the website
If the thread being forked is to preserve state while the client is logged in then I would use a database, memory cache, or some other persistance layer to hold the client session state. This is a much more typical model. You can also have multiple frontends that share session information across the network.
If you are not talking to a browser then creating a stand-alone web application may be the best choice. You can still use HTTP as your transfer protocol in which case I'd recommend using a Java web implementation like Jetty. This would involve significantly less technology and complexity.
If you need to implement web pages, I would certainly use proper frontend models and technology. You should separate your pages into multiple applets -- or multiple controllers/views in the MVC model. Using the applets should be fine. They (or the controllers) should call a centralized service which starts, communicates with, and stops the background threads depending on the information flow.
I would also certainly have another background thread running to time out your client threads in case a client never returns. Your worker threads could just exit after a certain amount of waiting.
Hope this helps.
is it possible for java thread created by java applet to continue execution after user navigated to another webpage (on the same website)? I assume that yes.
Yes. Threads that are forked will continue to run until they terminate or (if daemon) the process terminates.
is it possible for newly launched java applet to communicate with java thread already running in background?
Sure. What they need is some mechanism to be able to share data. For example, your background thread service could keep a Map of the thread objects with the key being some sort of client-id. Whenever a thread wanted to talk to it's background thread then it could call the service to lookup the thread by id. Something like:
BackgroundStream thread = threadService.getThread(clientId);
thread.callMethod(...);
If there was some sort of synchronous question/response then you'd need to have a condition variable or something. Read up on Java threads for more information.
There's an architecture used in Website applications in Java, it's called a Model-View-Controller. Frameworks such as Java Server Faces (Standard on Java EE 5 and higher), Struts (1.x or 2.x), Spring, Apache Wicket, etc. were designed to create web applications using MVC model. The question is, would you prefer the component-based architecture of the framework (such as JSF) or not (which you shouldn't be worried about at this moment)
Applets is defnitely a bad choice as applets are downloaded to client side. Some browsers don't support Applets especially in mobile web browsers and its difficult to apply security settings to untrusted applets, plus you may not know if the client has blocked the applet or not.
Applets are a bad choice because of 2 reasons:
1) First, they are executed on client's browser and not on server. Therefore you cannot perform any backend processing(Business logic or fetching data from server database) using applets.
2) Applets are very buggy and have security issues. That's why applets are out of fashion these days.
Now coming to how you can create website using java technology, for that you need to start understand Java Server Side programming. Start learning about Java Servlets and Java Server Pages. To put it in simple terms, they are java programs which are executed on a web-server or application server.
then start reading about Java Enterprise Edition.
refer this tutorial for Java Enterprise Edition
I want to create a process control application. Events update the database and that should be reflected on the GUI.
Although I personally prefer Linux, the hard fact it that 100% of the potential customers I can imagine run Windows.
Ok, for Windows I am comfortable with C++ Builder.
I suppose I could switch to NetBeans and use Java just in case someone ever wants it cross-platform.
browser based is probably the easiest way to cross-platform (barring some disagreements between browsers).
The thing about browser-based is I am not sure how to implement it. Would I auto-refresh the page every second or so? Can a database change be propagated upwards via PHP and refresh the screen? A very basic question, but I am new to this sort of thing, coming from an embedded background.
If all else is equal, which is easier for me to implement and maintain?
If it's real-time control, and you have to respond within a very narrow time band, then web based and Java based probably won't do it. If it's real-time control problem you ought to look elsewhere for a solution.
You can certainly use the web, Java and PHP to display results as they are produced, but the actual control and persistence to a database should be done with different technology.
I'd also be careful about writing to a database. It should be an asynchronous, "write behind" capability rather than the naive, "connect to a relational database and do an INSERT" sort of thing. I think that will be too slow.
If it is desired to be multiuser apllication I prefer web applications. Easy to make changes, easy to deploy. No problem with firewall settings and etc.
About propagation of changes from server to client. No way. But you can utilize AJAX tu "ping" on server and checking if somethink is changed. And if somethink is changed then load id and change view. Facebook/Google use somethink like this for chat/googletalk and so on.
About browser differencies. You can use CSS framework, JavaScript framework and most of problems with diferencies between browsers are solved.
Edit: If it is about seconds I think that PHP, Python or somethink really easy and fast is good part on server side. Or C++ CGI module. And on database side SQLite. Lightweight and fast solution for not much complex data. ANd not to big amount of data.
Before I jump both feet in and waste my time learning something that I can't use for my needs, I have to ask:
Can I make a http connection to another website from within a java applet or a flash file?
Say I have a java applet that wants to load results from google. Will the JVM give me access to such a call? What about Flash? I've read about URLLoader but am confused with the this:
" * Data loading is not allowed if the calling file is in the local-with-file-system sandbox and the target resource is from a network sandbox.
* Data loading is also not allowed if the calling file is from a network sandbox and the target resource is local."
Anyway if it isn't possible, will it fail on the user silently or will it ask for permission?
Thanks a lot.
Of course you can do that in Java, and also flash. However some browsers and environments may restrict by forcing security levels.
The warnings you found were related to local<->remote. For web applications which is hosted on network, you can usually access other network resources. (well, some may restrict you for "other" domains - you'll need to check the security models)
But modern technology usually suggest you to do that with the combination of JavaScript. Google for "Ajax" and search for some frameworks that best fits your requirement - that would save a lot of time.
Yes, but the problem is that for security reasons, many browsers only allow the application to connect to the domain from which the application came from.
so for example, if I go to website A and my app is trying to make an access to website B, it could sometimes be blocked (e.g., to avoid spamming, attacks, etc.). A work-around, if you control website A, is to create a "pass-through" script on website A that will send the request to B.
Can I make a http connection to another website from within a java applet or a flash file?
From Flash, yes. You do need to read up on the Flash Security Model to be sure what you can and what you cannot ask. Most of the time this is to stop unauthorized access and/or XSS or similar attacks. Flex (a related technology), for example, does not give you access to your disk, whereas AIR does. Take your pick.
As for applets, you'll have to wait for someone else to explain it to you. But AFAIK, it also has a security model to pose the least threat to its users.
Java, JavaScript, Flash, etc., implement some form of "same origin" policy which only allows untrusted code to read from the site it was downloaded from. One way around this, supported to some extent by recent versions of Flash and Java since 6u10 is crossdomain.xml (Google it). This allows sites to permit access via code downloaded by other sites. Note, this requires the site you want to access to grant you permission to do so.
Not with ease. By definitions Java sandbox won't let your applet call other than the origin it came from. You will have to sign your applet properly. Then users will either trust your applet and let it call elsewhere, or deny it - it's up to user. You can self-sign your applet, but I would personally never allow such thingy on my computer. It's good for testing and stuff like that. So you'd probably need to buy a certificate from reputable source. Same to the Flash, I believe the idea is identical.
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.