On 10/23/07, Don Brown <[EMAIL PROTECTED]> wrote: > I guess this is where we differ. I think we absolutely shouldn't be > creating new conventions because: > 1. The Rails conventions have been used for years and have proven valuable
Struts 1 has been used for years, and proven valuable. But that didn't stop WebWork from improving on the original. > 2. The Rails conventions match what people think about when they > think of a Restful URL Maybe I'm the odd duck, but they don't match the way I think. In fact, they seem haphazard and arbitrary. I expect they make better sense in the context of Rails, but we should use conventions that make sense in the context of Struts. IMHO, if we are linking the operations to CRUD terms, then we should use CRUD terms and not invent new vocabularies. > 3. Conventions are already difficult to learn and remember, so one > set of them is always better than one frequently used set and another > rarely used Agreed. The Struts 2 REST conventions should be based on our existing conventions. We don't call it "edit", we call it "input". Why not call "Read" read, "Create" create, and "Delete" delete? > 4. Using the same conventions minimizes training The documentation for the Rails conventions are bound to Ruby, and we'd will have to recast it all anyway. There is absolutely savings to be gained. > 5. The current URL patterns just aren't a good fit for Rest, so I > don't feel bad throwing them out. I just don't see that at all. The patterns described seen like an even better fit for REST. * http://cwiki.apache.org/S2PLUGINS/restful-crud-for-html-methods.html > 6. Struts 2 was all about not reinventing the wheel, and here is a > clear case where we can learn from another project Agreed. But, that doesn't mean we can improve on what the other project is doing, just as we have continued to improve the WebWork 2 codebase. > My ultimate goal is that Struts 2 realigns itself as the easiest, yet > most powerful way to write a Restful application, going head to head > with Rails and Restlets in this specific aspect. I think we have a > tremendous opportunity to capitalize on how well our architecture fits > Rest applications to meet this growing demand and be a leader in the > field. Mine too, but that doesn't mean we should blindly copy arbitrary conventions that don't fit well with existing Struts design patterns, without even considering alternatives. > I can't say it enough - Rest could be _the_ thing Struts 2 is known to > dominate in the Java web framework world, but do make that happen, it > would take a strong, if not unanimous consensus from the Struts > development community. Other frameworks have less configuration > (Wicket), have a better UI component model (JSF, Wicket, Tapestry, > etc), and even other action-based frameworks have a tighter focus and > leaner, yet practical codebase (Stripes), but we could have the > premier Rest platform, which I believe delivers solid, scalable value > to developers. I know that is where my applications are moving, and > I'd like Struts 2 to be the framework I use to write them. Agreed. But, again, RESTful resources and the Ruby conventions for REST are not synonyms. I admire Ruby, but I don't suffer from API envy. If we want strong, unanimous consent from the Struts2 community, then we should focus on developing conventions that Struts2 developers will find intuitive, and will also serve the purpose of RESTful resources. Though, I'm not sure if we are talking about RESTful resources as much as we are talking about automatic, heuristic mappings. Some web services can be truly RESTful when talking to the right server, but true REST isn't even achievable in a general web application framework. REST has some technical benefits in caching and such, but, in and of itself, it's not the holy grail. IMHO, it's the notion of automatic, heuristic mappings that make the real difference in web development. Anyway, talk is cheap. I'm more than willing to try a Ruby-RESTFul MailReader and then try another using the Struts2-like conventions, and then compare the results. -Ted. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
