> > > 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. >
I've been looking thru the free Derby book that we picked up at the apache conference. Derby might be a good fit for types of configuration. It's light weight and could run within the application. I don't get it. The core jar is only 2M? Now, configuration management and version control might be a different story but I know that some shops would rather managed metadata in a RDBMS than XML or within the source code. Those would be the shops that have a different release cycle for static content and configuration versus source code. I'm not sure that I agree with this distinction but I know that some do. > > > > > david > > > > Gary > > > > Craig Gary
