K, I think I see where you are coming from. I guess we are coming across a difference of opinion, but let me explain how I would do the exact same thing:
- Like you, I would have a single action class that has multiple methods to invoke (input, save, list, whatever)
- I would not, however, have different stacks. In fact, I go just the opposite: I try to have one global stack for every action. In cases like yours where the stack needs to behave differently, I design the interceptor to look for an annotation or convention, much like today's WorkflowInterceptor and ValidationInterceptor do.
- I would have one action configured (well, actually pulled in via convention) and then use foo!bar syntax.
What do you think of that?
course, my approach won't work with the efforts Don and Ted are pushing for: removing foo!bar syntax as a recommended option.
Ted, Don: what would you guys do in the scenario Jason provided?
I should point out that in my scenario, there is no need for any configuration - just some common conventions that tend to work very well (for me). I wouldn't even be happy doing a wildcard configuration for each entity, though I think that would be better than Jason's approach (assuming you could define a single stack with different behaviors).
Jason, I have to disagree with you on this. I've
written a lot of WebWork apps and multiple aliases
is
rarely used (maybe 1-5% of the time for me).
Perhaps
you can give the common examples you come across
so
that we can understand your style better?
I think I posted this last week, but here's the
Invoice CRUD action definitions:
<!-- Invoice CRUD Actions
<action name="listInvoice"
e"
class=""
method="list">
<interceptor-ref name="listStack"/
sult name="CRUD-list"
type="freemarker">/</re
sult
</action>
<action name="editInvoice"
"
class=""
<interceptor-ref name="editStack"/>
ction>
<action name="saveInvoice"
"
class=""
method="save">
<interceptor-ref name="crudStack"/>
ction>
<action name="deleteInvoice"
"
class=""
method="delete">
<interceptor-ref name="crudStack"/>
</action>
at for each entity in the system
Posted via Jive Forums
#77972
To unsubscribe, e-mail: dev-unsubscribe (AT) struts (DOT) apache.org
For additional commands, e-mail: dev-help (AT) struts (DOT) apache.org
No. 1# | By Developer Tags User at [2008-5-5] | size: 2688 bytes
8/3/06, Jason Carreira <forum-struts-dev (AT) opensymphony (DOT) comwrote:
Either way, you're still talking about multiple aliases for one class, which is what Ted was
saying we should deprecate.
Ted didn't say deprecate. Ted said that it didn't seem like a best
practice, in the same way that chaining actions is not a best
practice. Mainly because it goes against the grain of the "advanced"
features like type converters, localization, and especially
validation.
>For how it's done Well, I hate the "!" notation We've had to
jump through a lot of
>hoops to support it and it still bites us every now and again. Plus,
it's just a security hole,
>plain and simple.
Yes, and that we've already deprecated the bang-syntax. In the head,
it's only supported when a compatibility switch is turned on, and I
expect it would be removed entirely in 2.1.
The next question is whether there will be support for the
idiom. (Is there still support?)
*
(After commenting here, I began to rethink how strongly we should
support multiple aliases.)
I like the idea of wildcards, and I'd like to be able to specify certain wildcard patterns that
>can be used across many paths and specify interceptor stacks to go with them:
>
/entity/*/list -listStack
/entity/*/edit -editStack
and then
/entity/invoice/list
would match the first wildcard and have the specific listStack applied.
Me too. I think when we use multiple alaises, using multiple stacks is
a sane approach. It dodges using "magic" names to skip validation.
Though, it doesn't provide a way to validate a specific method, unless
we use Java or the ActionClass-method-validator idiom
This sort of special-case handling is why I'm leaning toward
one-method per Action. All the commands have a full array of extension
points, without any smoke or mirrors.
In the end, the complexity has to live somewhere. With
she-bang-magic-methods, it was living in the framework, creating a lot
of special-case code, and creating security issues. With
multiple-methods, the complexity moves to swapping stacks and maybe
doing some validations outside for the framework. With single-method,
the complexity moves to creating more classes.
-Ted
To unsubscribe, e-mail: dev-unsubscribe (AT) struts (DOT) apache.org
For additional commands, e-mail: dev-help (AT) struts (DOT) apache.org