On 12/22/05, Gary VanMatre <[EMAIL PROTECTED]> wrote: > > >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.
+1. The suggested approach would also necessitate getting the page author involved in flow related coding, instead of just the application architect. The current scheme requres zero code in a JSP page. 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. You need not limit yourself to visualizing ... constructing a page flow graphically with a tool also becomes very easy. (Creator currently does a simplified version of this for standard JSF navigation -- and many folks start on the Page Navigation editor and flesh out all their navigation, before they ever start coding individual pages). I agree that simpler is better but I think centralized configuration is > simpler in this case. I think centralized configuration is better for the dialog case, but I can still appreciate the "convention over configuration" argument in general. Indeed, I've already started down a path to reduce the amount of stuff you need to configure in faces-config.xml, if you're running on JDK 1.5 or later. Check out the "shale-tiger" library of extensions. In particular, the one that lets you declare managed beans with annotations, instead of having to configure them in XML. Note also ... the dialog manager does *not* care what technique you used to configure it! So it's still possible to experiment with non-XML approaches, as long as you end up with a configured set of beans representing the dialog structure. > > > david > > Gary > Craig
