"Whatever doesn't kill you makes you stronger". "Whatever doesn't break my build, makes it stronger"... everything else in next ++ version.
Arron. PS. In regards to populating multiple ActionForms. This is not an issue with... err... nested beans :p Ted Husted wrote: >I'd say that requiring Servlet 2.3 / 1.2 would justify a major version >increase, and so maybe we should start whiteboarding Struts 2.0 to use a >Filter instead of a Servlet for the controller. Among others, one thing >that just came up under the "would've and "should've" heading was >handling exceptions at the controller level. >In the heat of development, a few of the attribute and class names ended >up being a little confusing, like "validate" in the web.xml having >nothing to do with the validate method ;-) > >My suggestion would be that we put together a design and requirements >document for Struts 2.0. Work on the Struts 1.x branch would continue, >and would be used to concept-test any new functionality. For example, we >can't change the signature to Action.perform in 1.x, but we can easily >provide a base Action class to handle mapped exceptions. > >Where attribute names or class signatures change, we might start looking >at a upgrade program from the beginning that would ease migration later. >I strongly believe that the architecture and approach is sound, but with >the benefit of 20/20 hindsight, there are a number of minor details that >should be changed. > >So to start a Struts 2.0 list > >+ Require Servlet 2.3 / JSP 1.2 >+ Controller as Filter >+ Tag extensions as add-ons to JSPTL >+ PropertyEditor Support >+ Declarative exceptions handled by Controller >+ Multiple controllers, multiple configurations >+ Direct support for Commons Workflow >+ Direct support for chaining Actions without a forward or redirect >+ More entry points in class methods for subclassing >+ Reconsider all class and attribute names, to make the heirarchy more >accessible to newcomers. > >Another thing that people often up is populating multiple ActionForms. >I'm not sure what the use case here is, but we should determine if >that's something we should be doing, or if it is a documentation issue. > >Backing an ActionForm with a map to create "dynamic properties" finally >seems to be addressed with the latest BeanUtils syntax, but we should >probably visit that issue as well. Perhaps a standard base class so that >we can better document the approach. > >Again, I would suggest that, where practical, we first retrofit Struts >1.x with any new functionality proposed for Struts 2.x, as a proof of >concept. In many cases, the Struts 2.x functionality would be superior >(as in the case of declarative exceptions), but it's important that we >leverage the existing code base, and get the features "out there" so >developers can bring back their experiences back to the table. This will >also help keep us from putting off to 2.0 things we could actually do >today ;-) > >-Ted. > > >"Craig R. McClanahan" wrote: > >>I think the question being asked here is "will the Struts controller >>functionality (currently implemented in ActionServlet) be implemented as a >>javax.servlet.Filter from the Servlet 2.3 API?" It's a pretty interesting >>question. >> >>Had the Servlet 2.3 API been available when Struts was originally >>designed, it's a pretty sure bet that I would have implemented the >>controller as a Filter instead of as a Servlet. This would have made >>possible some interesting approaches to using the Struts controller in >>front of (or in front of part of) existing applications that are being >>migrated to Struts, as well as the "multiple controllers per webapp" >>paradigm that we are currently discussing. >> >>However, that's not what happened. Struts is currently based on the >>facilities of Servlet 2.2 and JSP 1.1, because that provides support on >>the very broad range of application servers that support these APIs. I >>feel that we ultimately want to migrate to Servlet 2.3 / JSP 1.2 to take >>advantage of the new facilities -- the quesion is, when? >> >>We certainly need to continue to support the ability to run Struts based >>applications on a Servlet 2.2 / JSP 1.1 platform for the forseeable >>future. However, there are many compelling features of the next >>generation APIs that are worth supporting. I'd like to see us explore >>taking advantage of those capabilities by offering enhanced (or >>alternative) implementations of the basic Struts controller functionality >>based on the new APIs. >> >>What do the other developers think? Are there enough Servlet 2.3 / JSP >>1.2 environments available (obviously, I will be using Tomcat 4 for this, >>since I'm pretty intimiate with its internals :-) to make development >>*and deployment* of Servlet 2.3 / JSP 1.2 based applications useful, or is >>it still a little too early? >> >>Even if it's too early, we can start exploring those sorts of ideas so >>that we're ready when the platforms are readily available. >> >>Craig >> > >-- >To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> >For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
