I want to introduce a question that perhaps some of you are wondering. Even if you are not, you should be.
Should I be using Seam?
If you are using JSF, my professional recommendation is that you would be crazy not to use Seam. Adding Seam to your application does not take away from your JSF investment in any way. It doesn't make your application less "pure". And it doesn't lock you in to JBoss AS in any way.
What Seam does do for you is make your JSF problems just melt away and it gives you far more control over each request. Just to name one feature (and what got me into Seam) is the front controller (called page actions) that it brings to JSF. It also makes you a heck of a lot more productive. I have yet to hear and argument as to why you shouldn't use Seam if you are using JSF.
As for the rest of you, Seam has something to offer that few other frameworks provide. Conversations and state management. When you are developing a Struts or Spring MVC application, where do you store variables? Do you store them in the HTTP session? That gets you into trouble with memory and cross browser tab interference. Do you store them in hidden fields? That sure is a lot of work and how to you preserve object identity? Do you use request parameters? Request parameters are the same thing as hidden form fields. Seam gives you either the page or conversation scope where you can store data for a sequence of requests. The conversation is especially useful because it works even when using ad-hoc navigation.
As I always say, software is never perfect. But Seam has stuff that other frameworks simply don't have. The best part is, if you are Spring developer, you don't have to give up Spring to use Seam because the integration between the two is quite good.
As a final word, I will say that if you are serious about learning Seam, then you have the best chance of achieving your goal if you read Seam in Action. This is not a shameless plug, this is a service to you. I put every last ounce of energy into identifying all of the ins and outs of Seam and distilled them into one convenient location for you to consult. The more successful you are with Seam, the happier I will be. [ August 06, 2008: Message edited by: Dan Allen ]
1. We can directly use Hibernate Objects into JSF forms. In the past when I use to work with Struts I always have a question, why do we need actionform object filled from hibernate or DAO object while we can directly bring dao or hibernate objects in Struts forms.
2. use of s:ConverEntity enabls us to directly use Collection entity objects.
3. The richest GUI support becauseo of myfaces and richfaces. And as Dan, mentioned because of the use of JSF totally component based approach.
And offcourse the biggest negative point: Untill you don't have very good understanding of Seam concepts, development will take a lot longer time then using frameworks like Struts. So initial learning is time consuming. But once you learn it you will be fastest developer for developing one of the best application in industry
Another negative point: seam documentation is not perfect, you will not find lot of information on internate unless you own 'Seam in Action' [ August 07, 2008: Message edited by: Jignesh Patel ]
posted 11 years ago
One of the incredible things I have discovered about Seam is that I have now subconsciously switched back to use VIM to write Java code (actually Groovy code since I don't need all the damn imports). That really says something about this framework. I used to write PHP back in the day and I loved it because I didn't have to open up some honkin' IDE just to get some code running quickly. With seam-gen and VIM, I can write a Seam application right from the terminal screen.
I realize that an IDE offers tons of great stuff, and I am certainly not telling you to avoid using it. I'm just saying that you can go to both extremes. Take it with a grain of salt, though. I did just wrote a book on Seam, so I can tell you the package names of the classes and annotations in my sleep. Actually, my wife has told me that I have, on occation.