>From: David Geary <[EMAIL PROTECTED]> > This is from a blog entry about my Shale presentation at Javapolis at > http://blog.dannynet.net/: > > The other presentation was about Shale , by > > David Geary (who has some interesting blog > entriesabout > 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? >
I think that this approach would limit your reuse. Part of the benefit of the dialog is that you can reuse views and wire them together in different workflows and add processing logic between the navigation of the pages. If you hard wire a jsp to a specific dialog using some kind of annotation, you would loose the ability to reuse this view in another process flow. I think that another benefit of defining the dialog in one place is that you can visualize the overall flow. If this metadata was disbursed into various view fragments, it would be hard to validate and hard to justify the need of a dialog manager. I agree that simpler is better but I think centralized configuration is simpler in this case. > > david Gary
