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.
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.
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.
We want to write a UI that consists of HTML, Javascript (JQuery) and CSS. Although the initial starting point will be served up by a web server, there won't be any sever side templating. The browser will interact with the server via a restful interface and render its UI.
What are the risks of this approach?
Ideally I'd like a nice, straightforward javascript OO api which underneath makes http calls to the server to get JSON representations of resources. Any suggestions as to how this could be structured?
Anyone have experience with browser side templating?
Is there a framework to make this style of development easier?
We will also be defining the server side resources and my thoughts are to follow ruby on rails conventions. For example, if you define a Users resource in routes.rb, you have 7 uri templates. Any thoughts?
By the way, the server side functionality will be developed in java.
I have plenty of experience with this approach. I can guarantee you that it works - how well in the long run, I don't know yet but I'm extremely happy with it (as a developer).
You do need to make sure that you've mastered Javascript. Read up on the state of the art, at least check Douglas Crockford's work, and most notably JSLint.
As for frameworks, this is where your vision comes in. We've built one from scratch because we need a combination of tools that existing frameworks don't and because we think we have the vision and expertise to carry it through. You have to compare the pro's and con's. If you use an existing framework you have very little control over it's direction or the speed at which bugs are found and fixed. If you build one yourself you could run the risk of making wrong decisions and ending up with a framework that doesn't quite work.
I have noticed that in our applications the custom server side code is only very small. This means the importance of the backend is only very small (validation, sanity, authorization). We use PHP, but simply because we have loads of experience with PHP.
There are definitely risks. In the startup and early transition I have noticed that 'lesser' programmers have trouble catching up. There is a very steep learning curve for anyone not too familiar with Javascript and it's many elegances.
Another risk is performance. We're advising our customers to use Google Chrome, simply because
And then there is compatibility. The idea of a framework is that it's able to hide this complexity. Luckily browsers are increasing in-tune in accordance to standards but backwards compatibility with (for instance) IE6 is incredibly difficult.
I would advise against using jQuery. I find jQuery more of a 'plugin' than an actual framework. jQuery really shines when you have a website and you want to sprinkle on some fanciness. It has some very good general tools (DOM manipulation and all that) but it's very lacking in the business-modeling area.
I would also advise against an OO approach. For some very small number of domains OO is the perfect solution. For most businesses, it's not. And Javascript is capable of so much more than just OO.
The #1 problem (and, perhaps, the only problem) is search engine. It is not sure how well will your content be recognized/crawalble/searchable. The underyling cause is that the search engine is not necessarily going to understand your content (since it is only revealed once Javascript gets executed).
Other than that, it is a great approach. I tried it several times and it works great (assuming you're not intimidated by Javascript). The resulting web-site is usually much more responsive than traditional web-sites since the server -> client traffic is quite small - only the raw data is transmitted. All the UI stuff is generated, by Javascript, on the client side.
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.