Dale Newfield wrote:
Using the staticParams interceptor that should be straightforward.
Except that in the default stacks, an instance of "params" follows
"staticParams", which would allow these action definitions to be
overridden (which I don't want). I will change the order in my own
stack, but I figured I'd ask why it is the way it is? Wouldn't it be
the case for most people that specify params in the action definition
that they wouldn't want those overridden by request params?
I don't know the history but I think you make a good point.
-Dale
P.S.: I figure someone will say: "This is silly--you should use REST
to specify all those constraints in a single action definition!" I
don't disagree, but I'm confused how to apply that--my constraints are
ternary in nature (for each noun in my system, when a constraint is
specified there's "What noun is involved?" "What is the relationship
to that noun?" and "What's the url-friendly name for the instance of
that noun?"). Also, since codebehind/smarturls/etc. are still moving
targets, which should I develop to?
I think you've done a good thing in your example. At least your decision
to create three different actions with a unique url for each type of
resource should make REST purists happier than the original generic
form. Since you asked, the REST plugin with the
NamedVariablePatternMatcher enabled would allow you to move some params
into the path to tidy it up a bit (and address each resource with a
unique url):
http://localhost:8080/seenabout/spiralween2007/allEventMedia.html
or using the default index action supplied by CodeBehind with the REST
Plugin:
http://localhost:8080/seenabout/spiralween2007/
I'm not sure yet what I'd do with the username param though (probably
leave it as a param).
I don't think SmartURLs helps a great deal in your case. You'd probably
have to create three action subclasses (each in a difference
namespace/package), in which case static params wouldn't be advantageous
anyway. The benefit would have been less effort writing and configuring
the actions (in that the URLs and params are implicit) had you decided
to use SmartURLs in the first place.
regards,
Jeromy Evans
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
