Hei If we where to look into a better configuration control, I would suggest taking a close look at Apache Jackrabbit (JSR-170). This gives among a lot of good things, versioning. You can even run with (Embedded) Derby as a backend, or just a plain XML structure if you prefer. I have been testing it for the last couple of weeks as a possible storage for a web application. During this testing, it struck me that the configuration in Shale/Clay might be a good candidate for this. I guess I would have to rewrite the Configuration handler to read its data from this new store. One of the nice features in Jackrabbit is the possibility to have listeners on it, meaning one would be able to reconfigure Shale "on the fly" so to speak through a GUI quite easily.
Hermod -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Friday, December 23, 2005 5:10 AM To: Struts Developers List Subject: Re: [shale] Dialogs and Convention over Configuration > > > 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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * This email with attachments is solely for the use of the individual or entity to whom it is addressed. Please also be aware that the DnB NOR Group cannot accept any payment orders or other legally binding correspondence with customers as a part of an email. This email message has been virus checked by the virus programs used in the DnB NOR Group. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
