Time to catch up with my Struts emails ... I haven't looked at Shale Tiger yet so I can't comment on that part.
As for the dialogs, I prefer XML configuration similar to what we already have. Our dialogs are pretty complicated and its hard to imagine the more sophisticated aspects of Shale dialogs (like subdialog and conditional forwarding) working without something as "complicated" as we have now with XML. As for managed beans, that's a different story. I definitely think its a PITA to configure your managed beans in XML. Maybe there's a possible Shale feature that allows you to use naming conventions to instatiate your managed beans (and view controllers for that matter.) Sean On 12/23/05, David Geary <[EMAIL PROTECTED]> wrote: > 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 > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
