On Nov 1, 2007 10:21 PM, Brian Pontarelli <[EMAIL PROTECTED]> wrote: > I have written ~10 applications to date using it:
Yes, but we also need public example applications that demonstrate a range of workflows. If we want to mark something GA, it's important that developers like Jeromy can build applications with it too. To learn another lesson from Rails and .NET, we should not only release the code but a set of best practices as to how to use the code. For example, right now, the MailReader is using the bang (!) alias syntax, so there are URIs like "update!input" that lead to a update-input page. Is there a way to get rid of that inconsistency, so all the URIs look the same, or do we need to implement a way for update-input to resolve to Update.input()? * http://code.google.com/p/smarturls-s2/issues/detail?id=16 The "bang" inconsistency already confused me. (Admittedly, not difficult to do!) I wondered why I couldn't redirect to another namespace. When I came back to the application a few weeks later, I realized I was trying to redirect to "update-input" instead of "update!input". These are the little pain-points that cost us hours and days of head-scratching. > I think my point is that although it has some downsides, it is live in > production sites and is working. It obviously can use improvements, but > I tend to feel that it works and makes things simpler than using XML. I > don't see gaping holes that need to be addressed and from my > perspective, anything we might add would be niceties and enhancements, > not fundamental changes of direction. Agreed. Everything I've found is already on the SmartURLs issue list, and it's a very short list. What's missing is usage examples, and especially an test-suite application that exercises the key features. I nervously applied some patches yesterday, and the reason I was nervous is that I didn't have a good way to QA the changes. Though, I do think that changing the way the Action packages are specified, or adopting a hierarchal view of namespaces are still significant changes. If this code were already released, those are changes that would take us from 1.0 to 2.0. Likewise, a solution to the redirect-after-successful-POST could also force a major version change, even if it is not a "fundamental" change. > I'm scared to sit on it too long. IIt doesn't have to be long. How about just long enough to consider the short-list of SmartURLs issues, add a test-suite application, and see if we can lure guys like Jeromy on board? :) Honestly, I feel we could have a 1.0 SmartURLs plugin for Struts 2.0 much sooner than we will ever have a Struts 2.1 release. And, I also feel that we would have a Struts 2.1 sooner if we do the right thing with SmartURLs now. You know, in terms of moving this along, a test-suite application might be even more important that a formal specification, since a test-suite application could be used to demonstrate backward-compatibility. I'm thinking of something like the taglib "Exercise" application we have for Struts 1. It's not a cookbook or a showcase, it's straight-up bare-bones tests that prove the tags work as expected. Of course, the application is also defining our expectations :) Meanwhile, the very next thing on my list is a JPA SmartURLs MailReader. If we really want to do ourselves a favor, we will be very sure that our conventions mesh hand-in-glove with the JPA :) -Ted. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
