For Struts Next, here are my personal goals. * xStruts.
I would like Struts to become a framework so elegant that developers working in other environments will want to implement it too. IOW, the xUnit of web development frameworks. Overarching vision: "Share the wealth." * Struts DAO. Today, the framework seamlessly integrates XWork, OGNL, and Spring, and FreeMarker with JSP or Velocity. Through Results, we integrate with JasperReports, PDF, JFreeCharts, and so forth. Next, we should look toward providing the same type of seamless integration with Cayene, iBATIS, JDO, or as a third-party option, Hibernate. Overarching vision: "Play well with others." * Struts Stack. Bundle a proven set of extensions with Struts Core to create a complete MVC web development development, powerful enough to create "best of breed" applications, like Confluence and Jive, "out of the box". Extension could include packages like Display Tag, Struts Menu, Acergi, Web Flow, and iBATIS or Cayenne (Sadly, Hibernate is still LGPL), along with an example development platform featuring Eclipse, HSQL, Jetty, Subversion, MailMan, and Trac. The Stack would be "proven" with a range of practical example applications, backed by realistic requirements and use cases. Overarching vision: "Soup to nuts." * Struts Plugins. Right now, Struts 2 is a "pluggable" framework. We start with a set of interfaces, and plugin a proven, general-purpose implementation. As it stands, we implement plugins using two approaches, "bootstrap" and "config-behind-code". In both cases, the "plugins" are just XML documents. Some bootstrap documents are bundled in the JAR, others are provided by the application. At startup, the framework is hardwired to look for the "bootstrap" configuration documents, like struts-default.xml (packages), default.xml (validators), struts.xml (custom packages), which can in turn bootstrap other configuration documents. At runtime, the framework looks for "config-behind-code" plugins, like "Classname-validation.xml", "Classname-conversion.properties", and "Classname.properties" (localization). I'd suggest that we try to adopt a consistent approach to plugins so that everything is configured the same way. Ideally, we should not be tempted to include "optional" members that only work when we provide a third-party JAR with our application. We should be able to drop in a plugin configuration as easily as we drop in a JAR. By utilizing a clear plugin strategy, we can avoid distribution bloat while making it easier for both novice *and* expert developers to create the optimum environment for any given application. Overarching vision: "Less is more" -Ted. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
