This is from a blog entry about my Shale presentation at Javapolis at http://blog.dannynet.net/:
The other presentation was about Shale <http://struts.apache.org/shale>, by > David Geary (who has some interesting blog > entries<http://www.jroller.com/page/dgeary/Weblog?catname=%2FRuby+on+Rails>about > his experiences with Ruby and Rails by the way). Shale is named 'the > new Struts', but technically it doesn't have much to do with Struts—and > maybe that's just as well. It's based heavily on JSF for its web interface, > but it also borrows from Tapestry, Seam, and Spring WebFlow; although > Shale's webflow mechanism seems to be somewhat easier to use. Yes. However, now that I've seen Ruby on Rails, it occurred to me how insanely > many XML config files are still used by something like Shale. I hadn't > expected this from someone so enthousiastic about Rails. Is it really > impossible to have anything in Java without a heap of XML files accompanying > it? I don't think so; the EJB3 presentation showed that it is possible, > using annotations and convention over configuration. People are starting to > understand that developers want to code, not configurate! I've given around 100 talks on JSF and/or Shale in the past year alone, and I see this same sentiment repeatedly. People are tired of copious XML configuration, not the least of which are folks who've seen the light of convention over configuration with other frameworks such as Rails. Those folks are happy to let the framework dictate some non-consequential things such as directory structure in return for the benefits of near-zero configuration. So, this guy's comments finally got me thinking: do we really need an XML config file for Shale Web Flow? If we could do away with that artifact, we could make web flow even easier to use and differentiate ourselves further from Spring Web Flow. Off the top of my head, I don't see why we couldn't define dialog structure with filesystem conventions and flow with custom tags in JSP pages. For example, by default, a root dialog directory named WEB-INF/dialogs (users could override with a context init param) could hold subdirectories that represent individual dialogs. Each JSP page would represent a view. Each JSP page could have a single custom tag that specifies the transitions out of the page (similar in spirit to moving metadata from XML files to annotations in Java code). For those that prefer explicit configuration, we can still provide the XML option, but it would be nice to give users the choice. Thoughts? david
