I'm not advocating my off the cuff solution, which of course has drawbacks. I'm just suggesting that we think about something along these lines. I wouldn't mind seeing a less powerful interface, if you will, into dialogs that requires no configuration.
btw, it seems to me that, to some degree, COC is usually a trade-off. You're bound to loose some capabilities, but that's usually acceptable for the return. For example, even with annotations over XML for defining managed beans, you loose centralized configuration, but the return--getting rid of the XML--seems to be worth that loss. At least until developers turn on annotations the way they turned on XML. 8-} Having said that, I think the Shale-tiger additions will be very well received. david 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 >
