On 10/30/06, Alexandru Popescu <[EMAIL PROTECTED]> wrote:
I quite agree with Konstantin. Adding more and more configuration stuff is not very good imo. In fact right now I am thinking/working about a light version of WW/Struts2 where the configuration is completely reduced (the biggest problem I have is with interceptors, for which I cannot figure out a way to deduce them from context :-( ).
+1 as to work on a light version. Feel free to commit whatever you have to sandbox. :) Though the existence of a light version shouldn't block work on the "enterprise" version. Simplifying configuration is a critical goal. One of the most confusing parts of using frameworks like ours is the forrest of configuration points. XML-here. Properties-there. :) This-name. That-name. In my ladies' chamber :) More than anything else, I believe we need a single source of configuration that can be expressed as a single stream or in multiple streams, as needed. But, whether single or multiple, it's the same configuration strategy throughout. One configuration to rule them all. Once we have one configuration, finding alternatives to XML would be a simplier task, and it would be easier to be sure that the alternative can do it all. But, we should be careful that simplifying configuration does not become an excuse for catering to the lowest common denominator. We should continue to address the truly tough use cases facing enterprise developers today. Elegant solutions to complex problems. Both Struts 1 and Struts 2 give developers an excellent head-start. We address many key use cases "out of the box", but there are still many more to go. Do we really have a truly excellent solution to presenting different pages based on security role, or locale, or browser, ajax mode, or a combination of all of these? If so, let's apply our strategy to the Showcase, and show everyone how it is done. Likewise, do we really have a truly excellent out-of-the-box solution to create wizards, like the JIRA mass-edit wizard? Or, for loading localized messages from a database (as Struts 1 can)? Or, for providing fully customized versions of a single application to any number of hosted clients? Or, for creating dynamic, validated input forms based on a database result set? We've only just begun to scratch the surface of what we need on-hand to create and maintain truly rich enterprise-grade applications. Don has expressed a complex problem, so what's the elegant solution? -Ted. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
