struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ted Husted" <>
Subject Re: [PROPOSAL] Merge Able/Code Behind/Zero-Config/SmartURLs into view-behind specification
Date Fri, 02 Nov 2007 00:47:31 GMT
On Nov 1, 2007 5:02 PM, Brian Pontarelli <> 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),


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

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


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message