How can I best connect Seam and GWT in a stateful web application?

By : larsivi

We have a web application that was implemented using GWT. What it presents is fetched from a Jboss/Seam server using the remoting mechanism, and this works fine. However, the application is now extended to support sessions and users. The Seam GWT service doesn't seem to provide a way to let me log in such that Seam can return restricted data back to the GWT application, and so it looks to me that I will have to wrap the GWT application in facelets.

It is not obvious to me that a login using the Seam session mechanism will help me get correct data into the GWT application however, so my question is whether I will be lucky and it will just work, or if I need to do some client side magic, server side magic or if my perception of missing login functionality in the Seam GWT service actually is wrong.

Bonus points to anyone that can provide me with a complete example showing something similar.

By : larsivi


It turns out that things are "just working" as I hoped. By using Seam's Identity and login mechanism, I can access the current logged in user via Identity.instance().getUsername(); in the service code that gets requests from the GWT portion of the application.

I tried to put a @Restrict annotation on the service, but this did not appear to work, however this is not something that is not needed as long as I can provide results to the GWT application based on the logged in user.

By : larsivi

How about this complete GWT app on google code -- ?

By : anjanb

Although there are certainly good articles on that topic, none of them is a substitute of real-world experience.

Maintainability is nothing you can plan straight ahead, except on very small projects. It is something you need to take care of during the whole project. In fact, creating loads of classes and infrastructure code in advance can produce code which is even harder to understand than naive spaghetti code.

So my advise is to clean up your existing projects, by continuously refactoring them. Look at the parts which were a pain to change, and strive for simpler solutions that are easier to understand and to adjust. If the code is even too bad for that, consider rewriting it from scratch.

Don't start new projects and expect them to succeed, just because your read some more articles or used a new framework. Instead, identify the failures of your existing projects and fix their specific problems. Whenever you need to change your code, ask yourself how to restructure it to support similar changes in the future. This is what you need to do anyway, because there will be similar changes in the future.

By doing those refactorings you'll stumble across various specific questions you can ask and read articles about. That way you'll learn more than by just asking general questions and reading general articles about maintenance and frameworks.

Start cleaning up your code today. Don't defer it to your future projects.

(The same is true for documentation. Everyone's first docs were very bad. After several months they turn out to be too verbose and filled with unimportant stuff. So complement the documentation with solutions to the problems you really had, because chances are good that next year you'll be confronted with a similar problem. Those experiences will improve your writing style more than any "how to write good" style guide.)

By : vog

This video can help you solving your question :)
By: admin