What is the 'best' server-side technology on Linux to use with Google Web Toolkit & why? I'd like opinions about:
JSF and other Java based server technologies
Rails
Django
PHP
GWT is a client side technology used to convert Java to JavaScript.
If you want to use GWT as a client code for a client-server application you should use a Java based server to avoid problems.
You can use the GWT-RPC with any language or you can even use your own JSON wrapping, but the easier solution is to use a Java server.
My recommendation would be GAE, TomCat or Jetty. Both Tomcat and Jetty are really easy to configure in Linux and TomCat integrates nicely with Eclipse.
The server technology has very little to do with it; use whatever you're most comfortable with.
If you want to take advantage of GWT-RPC to pass Java objects between browser and server, you'll obviously need a server written in Java, but any Java server container will work more or less the same.
If you don't care about GWT-RPC, your server can be in any language, Python/Django, .NET/ASP, PHP, Rails, anything. At that point you're just going to be hosting JavaScript files, even static hosting should work for you.
You could even write a GWT app that doesn't connect to a server at all, where the user downloads the JS directly, perhaps packaged as a Chrome extension.
The path of least resistance will be a Java servlet container like Apache Tomcat or Jetty. The GWT servlets are deployed in the servlet container, and call into your own code for the purpose of persistence and other server-side application logic. All of the presentation logic should reside in the client-side GWT code.
May I also recommend that you take a good look at the Scala programming language? It integrates very neatly with Java, and is therefore a perfect language in which to write your server-side logic.
In terms of client-server communication, I recommend gwt-dispatch to you. It has a good following, and streamlines the handling of requests and responses on both the client side and the server side.
Related
I have a question, I was developing a desktop web application based on a REST API in Java using Servlets and JSP, but my boss said that it's not the best way to create a web application, because servlets and JSP are working as fat/thick clients( a request to the server make the application to download all content of data not a part like GWT does) and he suggested to go with GWT because it is working as a thin client.
As I was looking on the Internet I didn't see that servlets are working as fat clients, so my question is why is better GWT than servlets?
GWT solves a different problem than servlets. GWT is a tool to make clients, and servlets/JSP are tools for telling servers what to send to clients.
For example, my server uses a JSP to serve a GWT client, and servlets to connect the client to my database. I use all at once! You could use just one.
You can make your GWT client arbitrarily thick or thin. You can even run a GWT application with no server at all.
Use GWT if you want a nice tool for making complex, cross-browser web apps in Java. The decision to use JSP or servlets should be made separately.
Is it possible to write a server side of GWT application in other languages then Java if yes how to use GWT-RPC mechanism, an sample code please
Thanks
Please read the GWT documentation Communication with the Server:
If you can run Java on the backend and are creating an interface for your application's server-side business logic, GWT RPC is probably your best choice. [...]
If your application talks to a server that cannot host Java servlets, or one that already uses another data format like JSON or XML, you can make HTTP requests to retrieve the data.
You can write your server in any language you choose, GWT is just JavaScript to be run in your users' browsers.
If you decide to go that route, you should look into using RequestFactory to communicate with your server instead of GWT-RPC, which is Java-specific. RequestFactory uses standard JSON, which any language can read/write.
Dont waist your time with GWT-RPC. It's bad. Use RequestFactory. I am surprised people are promoting GWT-RPC. It's a broken toy.
Is there a way to implement RESTful WebService using Spring 3 (or not) that does not use any web container?
Thank you !
I assume that the RESTful request will arrive over HTTP? So something needs to listen on the appropriate port and dispatch requests off to the service code. Obviously you can write such code, but you are likely to end up with something not very different from a Web Server.
If your objective is to embed this capability in some context then a lighweight container such as Jetty (as proposed by skaffman) seems like an answer - I'd be reluctant to write my own code instead
Using a framework such as JAX-RS makes writing REST services very easy, so if the actual objective is develop RESTful services quickly then I'd be prepared to live with a container that does the work for me.
In theory, yes - the various Spring-WS components are decoupled from the Servlet API. So you could, in theory, use the webserver built in to the Sun Java6 JRE.
In practice, this would be a lot of extra work. You'd have to bridge the Sun Web Server API to the Spring-WS API.
As an alternative to traditional Servlet containers, I can highly recommend Embedded Jetty, where your app can start up a lightweight servlet container within itself, and serve Spring-WS from that.
I am developing an application in GWT which needs to call a native C++ code in Directshow to do some multimedia processing.I am guessing that I cant use JNI because GWT converts code to javascript.I did have a look at similar posts on the forum(and on GWT site about JSNI) but cant find a example that specifically talks about calling C++ code from GWT(its mostly about calling Java code from Javascript).Can anyone throw some light on this or direct me to a tutorial?
Where exactly is this code supposed run? Surely not on the client-side. Client-side native code is nowhere near mass adoption.
GWT can either interface with JSNI in order to write native JS code inside your GWT Java code, or to interface with Java back-ends, whilst the framework handles the RPC. Even without GWT you have no way to run native code from within the browser (at least in the near future).
Bottom line - if you can't do it in plain vanilla Javascript on the client side, you can't do it in GWT.
What you can do is use this native code in the back-end, and call it via classic JNI from your Java back-end classes (and then what difference does it make if it's part of a GWT project or not?), but it sounds like this is not the case.
First of all, have a clear separation of Client (HTML / Javascript running in the browser) and server components (java service servlets).
If I understood your problem statement right, You need the UI to collect parameters for your transcoders and your transcoders need to run on a Windows box.
You can look up any simple GWT application to figure out how to serve a GWT application in any container (perhaps jetty for the time being) and process basic HTML form inputs. Once you have all the parameters on the server, you need to figure out how to delegate these parameters posted from the browser (your GWT application) from the service servlet (running within a web server) to your DirectShow application. This point onwards its a java application talking to a native process problem.
You can use various ways to communicate parameters to your native directshow application. Simplest solution is to initiate the application with the exec method passing command parameters inline. Otherwise you can communicate to a running native application via TCP sockets or integrate the native app using JNI. It all depends on your architectural design, which approach you wish to take.
For web application development, I've been steeped in dynamic languages such as Ruby, PHP, and Python. Using popular frameworks for these languages, all my knowledge about HTML, CSS, and JavaScript transfers fairly straightforwardly: templates are basically HTML with embedded code that the server executes to generate the dynamic sections of the page.
Lately, I've been thinking about using GWT for building the UI of my next project. At this point, I'm just trying to wrap my head around how development with GWT works, as seems to follow an entirely different paradigm. In addition, it seems there's an unstated assumption that the server-side part of the app is written in Java. Would it be impractical to use something other than Java for the server side?
Related question:
GWT + GAE python: frameworks for COMET & RPC
While not actually impractical I would say that you get the most value from GWT by having the same code on client and server, since it allows for easy code reuse (fx. if your data objects are serializable then you could just send them directly to the client). So I guess my answer would be; yes you can do it and it's going to be more work than just having Java on the server side.
I don't think there's any requirement that you use Java on the server. At the end of the day, GWT compiles Java to JavaScript. You can do all the comms via the RequestBuilder object, you don't have to use the RPC services.
I guess the question is: if you don't like/know/prefer Java on the server side, why would you use it on the client when it's effectively an abstraction over JavaScript anyway?
There is no requirement to use Java on the server side. GWT supports JSON out of the box. Any server side component that can generate JSON ( or other supported serialization methods ) will work. You could use PHP on the server side, or bash shell scripts, it doesn't matter to the Javascript code that is generated by GWT.
Yes, it can be practical. I use Rails as my backend and GWT/GXT as my frontend. I love every bit of it! I couldn't stand worrying about browser incompatibilities, so GWT/GXT was a real joy. Also, I had already started my backend in Rails and did not have much experience with Java on the server, so I stuck with Rails.
You may want to take a look at an appropriate GWT Rest framework, as you won't be using RPC.
As an aside, there is one exception where you should use Java on the server. That's if you want to use Google App Engine.
Feel free to ask me any specific questions and I'll be happy to help you out.
Good Luck.
-JP