On Nov 1, 2007 5:02 PM, Brian Pontarelli <[EMAIL PROTECTED]> wrote: > So, if I bang out this specification, which would include the existing > functionality with the changes above and a few other things I want to > add in terms of features (i.e. searching / interceptors / defaults / > exceptions / etc), would you feel comfortable writing the book against that?
Personally, I'd like to see three different applications written entirely with the conventions, before I'd be comfortable calling anything like this stable. Good examples might be the MailReader, the ShowCase, and a Struts Petstore. The point of the exercise is to make it easier to write applications. The one and only way for anyone to know if this stuff actually works is to eat our own dog food, and put it to work. Not just on what we are doing in-house, but on public examples, that we ourselves did not contrive, and that other people can review and dissect. Looking at the latest SmartURLs MailReader (r119), * http://people.apache.org/~husted/mail-reader-0.19-SNAPSHOT.war the biggest pain-point is redirects, and nothing we've done so far is addressing that concern. I'm sure we won't be able to solve the problem of when and where to redirect 100% of the time, but if we can use conventions even 80% of the time, we're starting to save actual effort. The common use case for redirecting is to redirect after a (successful) POST, mostly because we don't want them to resubmit again, and also because it usually signals the end of a workflow, and implies it's time to return to a menu or some other parent workflow. The POST part we could trap one way or another. The hinky part is where the redirect should go (at least by default). Now, as Brian mentioned, something else we haven't been doing is considering the namespaces an actual heirarchy. In both Struts 1 and Struts 2, the slashes are just characters, and the namespace is just a string. But, what if we adopting the convention of nesting namespaces to represent parent/child hierarchies. For example, in the MailReader, that would mean that instead of "register" and "subscribe" namespaces, we should have "register" and "register/subscribe", or even "/menu/register/subscribe". If we consider namespaces a hierarchy, and we adopt the convention of honoring Index pages, then a likely default behavior after a successful POST might be to redirect to "../Index", or to the first "higher" Index we find. Again, "redirecting up after post" won't eliminate the need to annotate redirects, but it may decimate the need. Of course, there are other pain-points in the MailReader, and I'm sure we'd find others in new implementations of the ShowCase and Petstore. But, the point of the plugin and the spec should be to identify what actually helps us write various applications ... and trying to lower our tolerance to pain :) Overall, my own preference would be to first finish what we've started with the SmartURLs plugin for Struts 2.0.x. When we can use it to write the simplest possible MailReader, ShowCase, and Petstore, then let's make bring it onboard as the new CodeBehind for Struts 2.1.x. If there's something that the CodeBehind does that SmartURLs doesn't do, then let's port that functionality over. As to the generic specification, for the last two years, I've spent half my time working in .NET, and it looks like that will be the status quo for at least a couple of years more. I'm really liking the heuristic mappings strategy, and, regardless of what else is happening, I'll be implementing a .NET version that we can use at work. -Ted. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
