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
