Leasons learned from using Seam
Yesterday, I noticed the Seam Developers released a new seamframework.org site. It's great to see a web framework team eating their own dog food. Of course, if all open source framework developers were paid full-time to work on their respective project, we'd likely see more of this.
My favorite part of the new site is the Forums, which has an Atom Feed you can use to monitor topics posted. This morning, I noticed a topic from Daniel Hinojosa titled ANN: amazinggates.com is alive with Seam & lessons learned. In this topic, Daniel lists a number of lessons he learned from working with Seam.
We deployed our web site at amazinggates using JBoss Seam. I would lie if I said it was it easy, but the reason I had some issues is that I didn't believe a lot of documentation.
- I had refused to use Facelets, instead I used JSP. All I can say to newbies is don't do it. You owe to yourself to drop JSP like a bad habit.
- I had refused to use Seam Managed Persistence and ended with LIES.
- I had refused to use Seam-Gen, and used my own folder structure. I still use my folder structure, but only after I used Seam-Gen and learned what I had to do to make my integration tests work.
- I had used 2.0 when it was still in CR and Beta releases. Although that is neither my fault or the Seam's fault, the greatest result was that I learned tremendously what Seam had to offer, and I was able to provide JBoss with some bugs, and help users in the forum.
- It took 8 hours to learn that Seam's AJAX4JSF solution was the best solution on the planet.
- I used faces-config for page navigation. Ok, and that was just stupid.
- I didn't know what components.xml was for the longest time. I'm really going to take part of the blame on this one. I read the documentation and even after reading it I still had no idea what components.xml was for. I realized that if the documentation said that components.xml maps components to names the way it does in Spring XML configuration. I wouldn't have spent that much time.
- I had refused to use Renderer.render for email, because I didn't believe that the view should be the place for the rendering. So I was going to use a StringTemplate solution. That was dumb, it took a while for me to realize that generating emails in the view was the BEST place to do so.
- Integration testing was a bitch. That wasn't my fault, or Seam's fault. It really was the Microcontainer's fault, and I hope that that ends up better in the long run. I heard through the grapevine that really no one is working on the EJB Microcontainer and it is still stuck in Alpha. Redhat needs to invest some people into it. It really is THAT important.
So, all in all, I love the new website, and I love what JBoss Seam has to offer. I am excited with what it has to offer, and I will still continue to build my business around it. Good work to the team that made JBoss Seam possible.
The one thing I noticed about Daniel's "Amazing Gates" site is it seems extremely fast. Do you think this is because of Seam or did he follow the rules for high performance websites?
Amaaaaazing Gates, how sweet the sound.... ;) The website looks really cool and feels very fast. The developers have spend some great work on this.
After some personal experience with Seam, I can somewhat agree with him. When using Seam you have to be open minded and get into their flow/ideas on how things should be built. That sometimes can help a lot, because they have had some brilliant ideas when designing Seam (conversations, their additions to Facelets and the usage of Ajax4JSF). You could run into trouble when you try to use Seam and dont do the things in the "Seam way", but your own way (like the original author tried to use JSP).
The main thing that made me not choose Seam in my current project was lack of ease of testability (JBoss Microcontainer, Seam Testcase classses for emulating the JSF lifecycle) and the loss of interactivity with your application that other frameworks provide ( e.g. Grails, although that does not mean that I would always choose Grails over Seam, it depends on the requirements).
I just love to be able to run "grails console" on the command line, have a GUI pop up and prototype some new functionality. The written code can then be used to write a unit test (grails create-unit-test ;) ) and form the basis of making it production ready. Is is so amazingly simple and FUN again, especially compared to the fact that Red Hat Developer Studio can hot-reload UI stuff but no business components.
Posted by Sakuraba on February 14, 2008 at 01:46 AM MST #
Posted by ken helfer on February 15, 2008 at 02:12 PM MST #
Posted by MyNetFaves : Web 2.0 Social Bookmarking on October 13, 2008 at 09:50 PM MDT #