Very applicable actually :) Let's look it this way - what types of information needs to go into configuration? I see the following types:
1. Action/Backing bean definitions. Perferably support for connecting with business objects. 2. Form/field definitions and validations. 3. ActionForwards/Navigation My understanding how these are handled by several major frameworks: Struts 1. Actions defined in struts-config.xml. No support for linking to business objects. 2. Forms defined in struts-config. Validations in validation-rules.xml 3. ActionForwards in struts-config.xml, no support for navigation JSF 1. Backing beans defined in faces-config.xml. Integration with Spring to connect to bus objects. 2. Forms and validations defined in the JSP's. No support for 1:M forms (save custom components) 3. No action forwards as page based. Navigation information stored in faces-config.xml Tapestry 1. Beans definied in each page's specification xml file. Support for bus object linking with hivemind. 2. Form fields defined in page spec file. No support for 1:M forms (save custom components). 3. No action forwards as page based. No explicit navigation configuration. One could argue Tapestry was the simplest, however it could also be argued the opposite since each page needs its own xml configuration file. The question is what and where do we want the user to be able to configure. On one extreme of configuration, NanoWeb/NanoWar require no configuration as the framework handles everything. On the other side, Struts seems to require configuration for everything. The "better" approach depends on your objectives and requirements, as well as personal taste. I'd argue Struts should continue to provide the maximum flexibility, but search for ways to provide intelligent defaults wherever possible to allow the new developer to be able to pick up Struts quickly, yet allow the advanced user the capability to customize the framework to their needs. I like Ted's one DTD idea to bring everything together, yet provide import-type capability to let those that perfer multiple files split out sections. I also like Spring's idea of separating the configuration from the code, to allow for alternate configuration schemes which may not even use XML. I think we should continue to strive for flexibility to allow innovative projects like Beehive to more easily explore new ideas and techniques. Don On Tue, 30 Nov 2004 10:47:23 -0600, Durham David R Jr Contr 805 CSPTS/SCE <[EMAIL PROTECTED]> wrote: > > Writing Java webapps should be easy. > > http://www.hacknot.info/hacknot/action/showEntry?eid=45 > > Kind of a lengthy read, but it seemed appropriate. > > - Dave > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
