I have some doubt regarding gwt file handling.
How to do file handling in gwt(at server side). How to create simple file. I mean which class is particularly used for CREATING and HANDLING it ??
Where is the file created. Is it under server package or somewhere else ??
How to resolve serialization and serialization problem. ??
GWT is a client-side technology. It's server-agnostic (and can also be used client-only, e.g. mobile apps, Chrome apps, browser extensions). GWT-RPC and RequestFactory use Java servlets by default (nothing precludes implementing RequestFactory in other languages/technologies) but have otherwise no requirement or limitations.
So, server-side, it's all just Java in most of the cases, and depends on your deployment target (e.g. AppEngine restricts what you can do, servlet containers can also have security policies in place, and you're of course dependent on authorizations at the filesystem level)
Since GWT is a pure client-side technology you have all possible options like plain Servlets for example. You are not limited in any way in picking the upload approach.
However, there is a number of open source projects, which make possible to use nice features like progress bars and multiple file uploads. And those come integrated with some GWT widgets as well. Check this project for example http://code.google.com/p/gwtupload/
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 read through the chromiumembedded usage and looked at the cefclient application. Now i would like to provide my gwt application as an standalone application to my customers. Is it possible to package the gwt client code using chromiummebedded.
I am not sure how to make the RPC/RC calls to the server if its packaged in CEF.
I think you need to include an embedded webserver in your application, and serve the generated GWT application files from this.
Since the url for your server will be different, you could disable the same origin policy in ChromiumEmbedded to use normal RPC calls, but it might be better to use cross domain calls as describe in Googles tutorial
while developing GWT apps we ran into lots of problems with project configuration. Let me explain... As usual in development, we have few environments for our application: local, demo, preview and live. Of course they are running on different machines, some are using SSL while others don't. But most importantly - all of them have different URLs.
Now, in few places in our application we need specify some URLs. Usually we would use *.properties files stored on server, and tools like Spring taglibs and it's <spring:message /> tag. But since GWT does not have such tools, we ended up in leaving hard coded URLs and performing code replacement on different SVN branches. As you can imagine - this is the worst possible scenario, causing us much problems.
So, my question is:
how one could build proper, flexible mechanism of storing config properties shared for both client and server side in GWT application. This properties have to be available for server-side handlers, client app (compiled JavaScript), UiBinder, other code running on server (workers, Spring, etc.).
The preferred way would be to avoid gwtc build if we change value of some property, but I guess it will be hard to achieve. So I will accept any reasonable alternative.
How about using relative URI references (e.g. absolute paths, without scheme or authority; i.e. /path/to/foo instead of http://example.com/path/to/foo)?
And in the few places where you absolutely need an URI (with scheme and authority), then use another property to store the "prefix" (e.g. http://example.com), and then concatenate with the above path.
Those places where you need a full URI should all be on the server, which means you don't have to recompile your GWT project when you change the "prefix", so everything is only runtime configuration and you can deploy the same artifacts in all environments.
That being said, if you ever need something configurable at runtime in GWT, then use a dynamic host page and JSNI (or a com.google.gwt.i18n.client.Dictionary); see http://code.google.com/webtoolkit/articles/dynamic_host_page.html
We're planning on creating a feedreader as a windows desktop- and iPad application. As we want to be able to show Websites AND to run (our own) JavaScript in this application, we thought about delivering the application as HTML/CSS/JavaScript, just wrapped by some .NET control or a Cocoa Touch webbrowser component. So the task at hand is to find out which framework to use to create the HTML/CSS/JS files to embed in the application.
For the development of the HTML/CSS/JavaScript we would be happy to use Vaadin, GWT, or some other framework, as we're a lot better with Java than with JS. We favor Vaadin after a short brainstorming, as the UI components are very nice, but I fear that most of the heavy lifting will be on the server and not in the client (and that wouldn't be too nice). We would also like GWT, but the Java-to-JS compiling takes a lot of time and an extra step, and slowed down development time in the past when using it.
The question is: which development framework would you choose (given you wanted to implement this project and you mostly did Java so far) and why? If there are better framework options (List of Rich Client Frameworks), please let me know.
Edit: The application will need to talk to our server from time to time (sync what has been read for example), but mainly should get the xml feeds itself. Therefore I hope that most of the generated code can be embedded in the application and there doesn't need to be heavy activity with our server.
Edit2: We (realistically even if you doubt) expect at least 10000 users.
Based on my experience with Vaadin, I'd go for that, but your requirements are somewhat favoring pure-GWT instead.
Vaadin needs the server and server connection. If building mostly offline desktop application, this can be solved with an embedded Jetty for example. (synchronize with an online service only when needed), but for iPad you would need to connect online right away to start the Vaadin application.
GWT runs completely at the client-side and you can build a JavaScript browser application that only connects when needed.
Because Vaadin is much quicker to develop, you could build a small Vaadin version first and see if that is actually problem on the iPad.
On the other hand, if you can assume going online right away, you can skip the local server installation altogether. Just run the application online and implement the desktop version using operating systems default browser control (i.e. the .NET control you suggested). Then Vaadin is easier.
Vaadin is just framework base on GWT but have two very important features:
don't need to run GWT compiler. It is pure java. Of course if not add addons because then gwt compiler must run.
you don't need to write communication code. So you don't need to solve DTO problems, non-serializable object mappings and dont need to write servlets.
I use Vaadin in my work for one year and we haven't performance problems yet (desktop like application with ~500 users). IMO very good solution is to use Vaadin just for UI, logic move to independent beans and connect this two elements using Spring or Guice.
In this case you should use MVP pattern and Domain Driven Development.
Bussines beans is domain objects and logic that use view interfaces to send responses.
Custom Vaadin components (could extends standard components) implements view interfaces.
That way is good when you decide to change UI engine if Vaadin is not for you. Just rewrite guice/spring mappings and write new implementations of view interfaces.
My 3 cents:
If you decide to use vaadin, You will benefit from already GOOD LOOKING components. Since you dont want to write (alot of) CSS , vaadin is already good looking out of the box. How ever, Vaadin is a SERVERSIDE framework. User interface interactions will hit the back end even if they dont involve getting any data (e.g moving from one tab to the other) .
If you decide to use GWT, you will have to atleast style the application (this is not hard) . There is also the problem of long compilation time (but you can test and debug on hosted mode which allows you to run the application without compiling , then you compile only when deploying). The main advantage of gwt is that you control what gets sent to the wire, For UI interactions that dont require getting data from the backend, it will work purely on the client side. You the developer will determine when to send a request to the back end. (Doing RPC requests in GWT is very easy)
Hope this will help you make the decision.
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