Last week marked the 1.0 release of JBoss Seam. This is the latest project from Hibernate founder Gavin King, and so I've been watching it closely over the past couple of months. I downloaded the 1.0 release and built its samples. None of them worked! This was very surprising. I went through the JBoss forums, and found the problem. Even though Seam 1.0 is GA, the version of JBoss that it needs is not. Luckily King posted a link to the beta installer. Once I used this version of the installer, the samples worked fine.
So what is Seam? I think the introduction given by King and other JBoss types is somewhat obtuse. They talk about a lot of different things that Seam involves, all tied around Annotated Pojo-components. Instead of talking about the cool things you can do with Seam, they should really talk about how easy it is to do some of these cool things. That's where its strength lies. Anything you can do with Seam you can do without Seam. It's that Seam makes some things easier.
Take a classic catalog example. You have a catalog of items. Each item has some info on it, name, price, description. You have two web pages, one for showing the list of items, one for adding a new item. With Seam, you would create two classes. One class for modeling the item and one class for providing an item service used by both pages.
For example, to get your catalog page to retrieve the catalog from the database, you would have some method like findItems() and would annotate it with @Factory("catalog") where "catalog" is some logical name for your list of items. Then you just tell your catalog page to use the "catalog" object (#{catalog} using JSF expression language) and Seam would automatically execute your findItems() method, which could initialize your "catalog" object using a query.
Similarly you could have a saveNewItem() method ony our service, and then in your edit item page you have a button whose action is "itemService.saveNewItem" where "itemService" is just a logical name for your item service.
This is a really simple example, but that's the point. You can do really simple things, really easily. That may seem like a silly statement, but if you've ever tried to write a Struts app that used a Stateless Session EJB and an Entity EJB ... well then you might have moved on to PHP or Ruby on Rails. Well that's essentially what's going on in the example given above. Ok, so JSF and Struts are not really equivalent, but you get the point.
My biggest sore spot with Seam has always been its use of JSF. I'm not a big fan of JSF. I know it was intended to allow for easier WYSIWYG development, but that's of little solace to me. However, its component lifecycle makes it work well with EJB3 and that's how you get Seam.
As for all of Seam's many other features... the new AJAX support sounds promising. I haven't tried it out yet. Sounds very similar to DWR, in that operations on your Seam components (like the item service mentioned above) are exposed via JavaScript. It uses a remoting servlet for processing AJAX requests (maybe they really are using DWR.) One amusing thing I found was that the JS libraries come from the servlet. The developer has to do a lot of the AJAX themselves -- triggering a JS call on some event, handling that event to make a remote call, processing the result of the remote call by updating the page DOM. Seam, like DWR, just makes it easy to make the remote call and get the results back. Seems like with the integrated component model, better AJAX support should be possible.
No comments:
Post a Comment