As a Java developer new to the web development environment, I was quite excited to find Grail which provides a great framework especially the convenience of abstracting DB operations with ORM. I later learned that it is actually the function of hibernate. At the same time I am delighted to learn about GWT. It is a god send for the project. I can continue building applications with event driven widgets using Java. Yeah!!
The answer seems clear: GWT + Hibernate. Will it work? What do I miss? Why there is much talk about this set up? What is the concern or area of risk? Have anyone tried this before?
Or, how do GWT developers handle the challenge of data persistence? What are the options?
Also I can't seem to find a good tutorial about setting up Hibernate with Eclipse -- the IDE I am familiar with. What are the tools or plug-ins needed?
Hibernate works fine with GWT as long as you keep in mind that the GWT code is actually running on the browser so you can't manipulate Hibernate objects in your client code. The downside to that is you're probably going to have duplicate objects on the client and server side, but you can use course-grained DTOs via the GWT remote procedure calls. On the server side, just create a ServletListener to initialize your Hibernate project and then use normal Hiberate methods to store and retrieve objects.
As far as Hibernate and Eclipse, Hibernate has an Eclipse plugin, but it's not really necessary to develop in Eclipse. It gives you the ability to run HQL and to reverse engineer Java objects from the database or vice versa, which can be useful, but it's not required.
If you want to go the hibernate way, you should have a look at Gilead or its predecessor hibernate4gwt. It works pretty well, but documentation is a bit sparse.
Related
I'm just looking through available technologies to create portlets using WSRP. So we have the following requirements (I'll try to explain so as I can):
backend part: Jax-WS webservices implementation (in fact JPA + some business logic)
frontend: portlets should use Jax-WS webservices and should be exposed through WSRP and consumed in Oracle WebCenter portal
everything should be built via Maven
I'm having troubles with selecting a proper framework for portlet development.
A couple of things which I'm considering:
ADF - has a big learning curve, tightly coupled to Oracle stack, I wouldn't like to use it
Vaadin framework - looks fine, but its latest version doesn't support WSRP Add on, so I will have to write something on my own
There are also a couple of others possible frameworks which I have not looked through yet: JSF, Spring Portlet MVC.
Maybe somebody of you has already used similar stack and can give some advice on which framework is more convenient for portlet with WSRP. I would very much appreciate any thoughts on that.
Thanks in advance
For me I used JSF with JSF-Portlet-Bridge, Struts and ADF
But I always preferred ADF since it gave me a quick way to generate WSRP portlets from Task-Flows.
If you are going to develop big list of Portlets, I'd tell you to consider ADF, even though the learning curve might be steep but it'll be worth it, and you already have knowledge in JSF it'll be an easy task!
First off, I've never used GWT before. I have good experience in HTML/CSS/JS/JSP.
I'm looking for people's opinions on the suitability of Google Web Toolkit for a brand new web app I'm developing.
A big requirement is that the UI is attractive and well designed (Does not look like a clunky Java/Swing App).
It should look like any typical HTML/CSS/JS based modern website.
It is an internal company application so no SEO is required.
JSF is not an option.
The web app frameworks used will be Spring Webflow and Spring MVC. It will use lightweight controllers to communicate with a service layer.
Would Spring Tiles combined with JSP be an easier or more flexible option than GWT for what I am trying to achieve?
Advantages/Disadvantages of GWT and other options welcome.
Thanks
Advantages of GWT
You don't really need to know any JavaScript, since all your client side code will be in Java
This is usually the main reason people go for GWT. They're backend developers who know Java but don't know Javascript, and they don't really want to learn it. Still, you should be careful about this. GWT is a very complete and complex framework with many concepts that are specific to GWT. Even though you'll be coding in Java you will still have to go through many tutorials and documentation before you can build a clean GWT app
Ready to use widgets, like date pickers, dynamic tables, layout panels, popups
It's not really specific to GWT. Other front end framework, like jQuery or Dojo or whatever also give you these. You can have a look at the GWT Showcase to see what GWT has to offer.
GWT takes care of a lot of complex and potentially dangerous stuff for you.
Stuff like Cross-Browser Support, Internationalization, Image and static resources bundling, Front end security, Ajax communication with a server, Events and MVP (just like MVC) framework support. Have a look at the documentation, it is very well done and very thorough.
Debugging is easy
GWT has two different 'modes'. When you're building your app for production, gwt will compile all the java code for the front-end that you wrote into javascript. This javascript will be executed in your clients' browsers. But when you're developping, you can run your app without compiling your java code to javascript. This lets you use a debugger to debug your interface. It's a very good tool.
Disadvantages of GWT
As I said before, GWT is a full framework, with concepts specific to it. Don't think that just because it's in java and you know java that you won't have to learn new stuff.
Interfacing GWT with back end frameworks is not easy
The most common way for your GWT client code to communicate with a server is by using GWT RPC mechanism. It means that you will need to have servlets that implement specific interfaces. You should definetly read the docs on client-server communication to see if that fits well with Spring. A search on SO or Google should give you pointers to setup your application.
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.
I'm starting new project. The client interface is based on GWT (and GXT) I have no say it's predetermined. However I can pick and choose as far as server side so I can have some fun and hopefully learn something new in the process. Some requirements are :
Exchange with server will be through use of JSON, most if not all of UI will be generated by GWT (JS) on the client, so the client/serve exchange will be limited to data exchange as much as possible
No Hibernate (it's not really supported on the proprietary db I will be connecting to). In the past projects people would use JDBC or iBATIS
Some sort of IoC (I'm thinking Guice just to stick with Google)
Some sort of Security framework based on LDAP. In the past we would use Spring security (Acegi) but it wasn't ideal and we had to customize it a lot
So basically should I stick with tried-and-true Spring/Acegi or try something based on Guice? And what that "something" would be and how mature is it?
Have a look at Apache Shiro. It seems to be gaining ground, with no reference to Spring.
If you'd like to do IOC on client and server, go with Guice. You can use Guice on the server, and its brother GIN on the client.
Since nether of the above answers gave me any practical ideas (or almost any) here's formula I ended up with:
Maven + GXT + GWT and Guice + iBaGuice
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