I would like to make a website using GWT, so I can use the java-to-javascript compiler for the client side. However, I would like to make a service that my client can call using the default RPC-mechanism of GWT, in Clojure instead of Java.
I don't know anything about Maven. I use Eclipse to generate and develop the GWT project. How do I set this up?
If you want to use GWT-RPC mechanism, you create three java files: two interfaces YourService.java and YourServiceAsync.java, and server-side implementation YourServiceImpl.java
Then you create Clojure code with business-logic, link it as library to the main GWT project.
Your implementation file will receive requests from client and call clojure for implementation.
I'd like to realize such approach too.
Related
I have 2 different gwt applications, both on different machines, but they need to communicate.
Is their a simple way, using the gwt mechanisem to do it and access an existing servlet on another gwt application, or do i need to open another http connection between them some other way?
The most standardized way to do that is to use JMX: it is future prone and a lot of work was already done for you.
http://en.wikipedia.org/wiki/Java_Management_Extensions
Your issue cannot be considered as a GWT problem since GWT is limited to java script, and you need real java methods to communicate together, doing it through GWT is at best unperformant and at worse the source of many problems (since you are not inside a browser, and using a "virtual browser" to execute your javascript might lead to subtile very hard to understand differences)
I have a Dart project want to reuse the existing GWT service (RemoteServiceServlet), any way can do this?
There is no special support for GWT-RPC included in Dart and there seem to be no 3rd-Party apps available that provide this functionality.
This question is similar (but not Dart)
GWT Data Serialization
If you're feeling ambitious, you can write a Dart client that understand the GWT-RPC wire-protocol and use that to communicate. This is likely to be a great deal of work however.
I had a similar situation where I needed to access GWT-RPC Services from a non-GWT client (it was JavaScript, not Dart, but the same concept applies). Instead of accessing the GWT-RPC service directly, I ended up using jsonrpc4j to setup a JSON-RPC service alongside GWT-RPC. I was able to point jsonrpc4j at the GWT services to use, so there was no code duplication, just the extra code needed to wire up the JSON-RPC.
Then you will need a Dart JSON-RPC client, of which there are a few available: jsonrpc, jsonrpc2.
This all assumes that you have access to the GWT server and can setup the JSON-RPC service.
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.
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