struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Geary <>
Subject [shale] Dialogs and Convention over Configuration
Date Wed, 21 Dec 2005 22:30:32 GMT
This is from a blog entry about my Shale presentation at Javapolis at

The other presentation was about Shale <>, by
> David Geary (who has some interesting blog entries<>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.


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

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.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message