Re: SmartURLs (fork of s2: problem with codebehind plugin)

[Brian Pontarelli]

Excellent feedback. Here's my thoughts:

 * Is SEO "Search Engine Optimization"? What makes hello-action more
compliant than HelloAction?

Most search engines do not understand or favor camel case as well as the dash or underscore. In fact, some engines will favor the dash character over underscores. So, that's why I set the default as the dash. Rails and others seems to follow this standard as well.

 * Would it be possible to support ReST-style parameters (which I
believe are also SEO-preferred), so that
"hello-world/save?message=Howdy" could be expressed
"hello-world/save/message/Howdy".

We could give it a shot. This is more of an ActionMapper concept than a smart URLs constraint. We could make a SmartURLs mapper that handles those.

   ** Something like "hello-world/save/+/message/Howdy" might work as
well, if including a parameter-start flag would simplify the code. (It
might simplify things for the developer too!)

Might. I've never made a mapper, so I would need to try before I knew exactly how easy or hard it was. I would imagine that a separator would simplify things a lot though.

 * Should we look for .html after .jsp, .ftl, .vm? Is the extension
list configurable?

This isn't currently configurable because it requires knowing the result type that handles the specific extension. e.g. the FreeMarkerResult handles *.ftl. We could have a JSON style configuration for it though:

{'ftl': 'freemarker', 'vm': 'velocity', ...}

I'd be up for that. OGNL would also work since it is the Struts standard for that kinda thing. We could just send the value to OGNL and get the Map<String, String> back.

 * Should we also look a page named for the result type in the current
namespace and the default namespace (/foo/hello-error.jsp,
/foo/error.jsp, /error.jsp, and then fall back to /foo/hello.jsp)?
   ** A key use for "global" result-code pages might be login.
   ** A side-effect would be that a page should probably NOT be named
"success.jsp" :) But, in my experience, when it comes to result pages,
success is local and failure is global.

Sounds like a good idea. I'd be up for adding it. Just need to think through all the semantics of it.

 * If we branch to another ${result} page, should we look for a
${result} action, and automatically chain the actions?

Hmmm. Also a good thought. Although automatic chaining might be dangerous. I tend to favor being explicit using the annotations when I'm chaining. But, it could work to fall back to chaining if no other results exist.

 * Could there be a smarturls.base.action.package that automatically
incorporated "sub" packages. Right now, it seems that we need to list
each and every package.
   ** smarturls.action.base.packages = "content"
   *** automatically includes content, content.foo, content.bar, ...

This is already how it works. If you have sub-packages they are added into their correct namespace. This is the same as the codebehind stuff as well. If you have com.example.actions.Foo and com.example.actions.bar.Baz you'll have these URLs:

/foo
/bar/baz

Unless I'm missing what you are asking. Or if you want all the sub-packages to be in the same namespace.... But if you are talking about that, I'd say it would be better to put all the actions into the same package since after all it is convention based.

 * Using "" for a the base.result.location exposes an exception.

Hmmm... Yeah, that could be an issue. hehe. You could probably use "/". I'll fix this today if I have time.

Thanks for the feedback.

smime.p7s
Description: S/MIME Cryptographic Signature