Well, it's mostly just a preference thing, so to be fair there's really
nothing wrong with the subclass approach. To me, extending an
ActionBean solely to use a different annotation for URL binding is a
"code smell."
I can see your point about trying to avoid having to extend Stripes.
The ActionResolver is made to be pluggable therefore I consider it to be
a relatively safe extension point. If I were a betting man I'd say that
this method would probably require little if any rework across Stripes
releases.
________________________________
From: Gregg Bolinger [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 05, 2008 9:54 AM
To: Stripes Users List
Subject: Re: [Stripes-users] Multiple URL Bindings
@Freddy: Ok so UrlBiding(bindings = {"binding1", "binding2}) then? :)
@Ryan: Thanks. The only real problem I have with this approach is I try
my hardest to let Stripes do what it does and only extend its
capabilities outside of the core API. Your approach would require me to
make these changes every time a new release of Stripes comes out. This
probably isn't as big a deal as I make it out to be but it is just a
personally policy I try to adhere to.
>I don't think you want to subclass the action to be able to use
multiple URL bindings. If it were a once-or-twice thing in the whole
app that would be one thing, but >otherwise I'd stay away from it.
I'm curious as to why you would stay away from it. What issues or
problems do you have with this approach?
Gregg
On Wed, Nov 5, 2008 at 7:14 AM, Asleson, Ryan <[EMAIL PROTECTED]>
wrote:
I don't think you want to subclass the action to be able to use
multiple URL bindings. If it were a once-or-twice thing in the whole
app that would be one thing, but otherwise I'd stay away from it.
What I did was subclass NameBasedActionResolver. My
implementation first looks at a simple properties file (no XML!) to see
if there are any override mappings for the current path. If so, use the
override, if not, delegate back to the superclass to get the correct
ActionBean. Be sure to wire up the new ActionResolver in web.xml. I
haven't actually used this in production, but I developed it when my
company was evaluating Stripes vs. Struts 2 and some wanted the
flexibility of multiple URL mappings.
Outside of being able to use annotations, I think this solution
is cleaner, despite the fact that there is a minimum amount of external
configuration in the form of a properties file.
Here are the "guts" of my custom NameBasedActionResolver:
====================================================
====================================================
Properties urlMappings = new Properties();
@Override
public void init(Configuration configuration) throws
Exception {
super.init(configuration);
loadUrlMappings();
}
protected void loadUrlMappings() {
try {
InputStream in =
this.getConfiguration().getServletContext().getResourceAsStream("/WEB-IN
F/url-mappings.properties");
urlMappings.load(in);
}
catch (IOException e) {
//@todo: log
}
}
@Override
public Class<? extends ActionBean> getActionBeanType(String
path) {
//first check the mappings to see if the path appears
there
String className = urlMappings.getProperty(path);
Class clazz = null;
if (className != null) {
try {
clazz = Class.forName(className);
}
catch (ClassNotFoundException e) {
//@todo: log
}
}
else {
clazz = super.getActionBeanType(path);
}
return clazz;
}
====================================================
====================================================
And here is an example mappings file:
/welcome.action=com.somecompany.stripesprototype.web.recognition.CardAct
ionBean
/home.action=com.somecompany.stripesprototype.web.recognition.CardAction
Bean
/blahblah/blah.action=com.somecompany.stripesprototype.web.recognition.C
ardActionBean
________________________________
From: Gregg Bolinger [mailto:[EMAIL PROTECTED]
Sent: Tuesday, November 04, 2008 3:02 PM
To: Stripes Users List
Subject: [Stripes-users] Multiple URL Bindings
I know this discussion has come up in the past and I'm not sure
how I feel about something like this:
@UrlBinding("/action/foo")
@UrlBinding("/Foo.action")
public class FooAction.... { }
However, I am in a situation where having more than one binding
would be useful. We are using Sitemesh so when I am dealing with ajax
and validation I can't simply return the error messages because they go
through the /* mapping and get decorated. If I change the UrlBinding
and exclude that path from sitemesh my main page request doesn't get
decorated. So I've thought of the following options:
1. Subclass the action class for all ajax related content that
I don't want decorated giving this sublcass a new url binding that whos
path is excluded in sitemesh.
2. Sublcass the action class for each new url binding I need
but leave all the meat in the parent class.
From a design perspective which one sounds better? Is there an
option I am not aware of?
Thanks.
Gregg
This e-mail message is being sent solely for use by the intended
recipient(s) and may contain confidential information. Any unauthorized
review, use, disclosure or distribution is prohibited. If you are not
the intended recipient, please contact the sender by phone or reply by
e-mail, delete the original message and destroy all copies. Thank you.
------------------------------------------------------------------------
-
This SF.Net email is sponsored by the Moblin Your Move
Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win
great prizes
Grand prize is a trip for two to an Open Source event anywhere
in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Stripes-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/stripes-users
This e-mail message is being sent solely for use by the intended recipient(s)
and may contain confidential information. Any unauthorized review, use,
disclosure or distribution is prohibited. If you are not the intended
recipient, please contact the sender by phone or reply by e-mail, delete the
original message and destroy all copies. Thank you.-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Stripes-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/stripes-users
