Brief for a Seam Treatise
Brief for a Seam Treatise
Join the DZone community and get the full member experience.Join For Free
Get the Edge with a Professional Java IDE. 30-day free trial.
Finally I have gotten back to Seam. See my prior arguments about it re:future of Java boiling down to Seam v. Spring. I will double down on my prior bet now. Does the best framework always win? No. But in this case, I am also starting to see a real groundswell: people who have suffered under plain old JSF and it‘s sub-glacial timelines, and of course, the inanity of Spring‘s ‘OpenSessionInView‘ (ironically, the spark that bore Seam), see Seam as salvation from a lot of painful suffering. But even people who don‘t bear the scars are able to see its value very quickly. Why? There is no Petzold answer here. There are some good books. I have Seam in Action which, while it's good, is a bit too scrappy, and gets wrapped up in seam-gen too much, and I reupped at Safari Books Online and found the book Seam Framework: Experience the Evolution of Java EE, Second Edition which is really good so far. It does a good job of introducing the user to the various features/services (love the name, btw, experience evolution… yeah). Going to drill down on some of the Seam elements here in some separate posts, especially the conversation support and the jbpm (again, not everything is a flow so conversations are a good idea and yet if you need one, the jbpm stuff is nice).
Meantime, a few months ago, the JBoss Portal team snuck out a release that implements JSR286. The primary advantage is AJAX works now properly. Speaking of which, the RichFaces components continue to improve. JSF has always been much better than Struts and other such wimpy procedural goo, but now it‘s getting to the stage where the arguments con are going to start looking silly.
Here are a few suggestions:
- The theme and skins mechanisms in JBoss portal are good, but someone needs to jump in and take the ui fungibility up another step. This is not to say that the capabilities are not good, rather, we are finally pulling close enough to finally put down the design by designer antipattern once and for all. (That is the tendency of design teams to want to play with designer ‘comps‘ because either the devs are not producing anything fast enough, or what they are producing is programmer ugly. This is the same void that gave tinkertoys like VB and Access their leg up in days of yore, but now, a few tools and real components that are skinnable and that look good is suturing this wound for good.)
- Simplest: do some screencasts showing some of the things that can be done by changing simple CSS elements in the skin.
- Offer some prizes for doing some better skins, and make the contestants provide guides to how they built them (this one would be confined to the portal server).
- The default look for the richfaces components is great, so I don‘t really have complaints about that. However, I am seeing that most programmers who come in contact with them have literally no idea where its look is coming from.
- On the portal side, there‘s a real need there to show that the design is flexible in some of the following ways:
- portal layouts tend to end up looking super boxy. Would be good to show some techniques for popping things out of frames, rounding edges, etc.
- Show us how to do some edgeless, or less edgy designs: where there are some areas of delineation, but they are more muted and traditional. It‘s easy to achieve this look, but it would be good to make it something devs can reach for rather than something a designer has to come in and work into the dough.
The identity management is another element that deserves its own posts, but suffice it to say a portal server only makes sense if it makes identity easy and integral. Huge points for this. Infoworld editors notwithstanding, the JBP competitor Liferay is a gaggle of test-free, diseased Struts code that offers almost no services, but just a simple way to quickly make something that looks decent. Now that JBP has built a solid foundation, it should just do some of this, but preferably outsource it.
Opinions expressed by DZone contributors are their own.