I'm wondering how you can satisfy both "Soup to nuts" and "Less is more" with one solution ... or are these multiple visions for multiple solutions?
For the record, I am not in favour of turning Struts into a "stack" solution. In my opinion, one of the strengths of Struts 1 was that we provided only the core web framework, and didn't make decisions for web developers as to which solution they should choose for persistence, etc. We were always very consious that if we were to choose one, it would be seen to be favoured above others, when that was not our intent. That being the case, it was clear that our users could select whatever best matched their application. And that last part - selecting the best match - brings me to the other reason that I don't want to see us going down the "stack" path. The problem is that we cannot possibly know what's best for our users' applications. Just as an example, in all the years that I've been developing Java web apps, not once have I been in a position to pick up an ORM package and use it for my app. Instead, the apps are all built upon custom APIs or services frameworks. With a "stack" solution, the first thing I would have to do it figure out (a) if and (b) how I can remove the pieces of the stack I don't want or need, and what the implications are for doing so. I know the response to this is going to be "but we want to provide the greatest leg up for our users", but the question is, what proportion of the framework's potential user base will really be able to use the entire stack that we might provide? And for those who can't, how will we convince them that they can unplug / replace the bits they don't want or need without having to know the internals of the framework? For that matter, how will we convince ourselves? -- Martin Cooper On 9/6/06, Ted Husted <[EMAIL PROTECTED]> wrote:
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]
