On 8/2/05, Dakota Jack <[EMAIL PROTECTED]> wrote: > > I agree for a third time, and in fact I think that something that is > built for Struts rather than on its own merits and is dependent on the > present community for support is not worth working on at all. I am > personally not willing to associate in an active way with anything > that is not IoC pure in both dependency and locator injection. I > think I am going to follow Ted's advice and begin coding completely > independent of but appreciative of the basic Struts controller ideas > and to see who wants to join in. If anyone is interested in pursuing > this from the bottom up and also understands what is going on, let me > know and we can work together on getting a base started. The first > thing I am going to do is to see if the web framework with Spring is > good enough to join. >
If IoC is your favorite architectural paradigm, you will definitely like Spring MVC -- it is consistently based on building up the front controller part of the application using Spring's IoC faciities, consistent with the way that everything else in a well-designed Spring app is configured. And, of course, you get seamless access to all the other stuff that Spring itself provides (which is a pretty substantial array of technology). On the other hand, if you really crave the "ActionForm is a POJO with typed properties and embedded action methods", take a look at WebWork or Tapestry or JSF -- all of which implement this basic concept today. Indeed, if I had thought of it at the time, Struts 1.x would have looked a lot more like WebWork in how it deals with the "action form" and "action" concepts. The interesting aspect of working on web frameworks today is that there is a plethora of options, many *very* well designed -- to the point where trying to start from scratch and build a new one, and then hope it gains enough popularity to impact the market, seems like an exercise in futility. That's one of the primary reasons I'm not going to be personally involved in coding whatever Struts 1.x turns into (unless Shale gets adopted as "Struts X.Y" at some point, of course :-). The only reasonable strategy that appeals to me is starting from a unique position compared to those other frameworks (build around JSF and avoid redundantly implementing all the stuff JSF already provides), which is what I'm doing with Shale. Craig PS: For a slightly more in depth comparison between the frameworks mentioned above, watch for me to post the slides for my O'Reilly Open Source Conference session tomorrow that compares them. You can't get *too* detailed in 45 minutes, but I try to provide at least an overview comparison about how the most popular frameworks deal with a common set of issues. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
