@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-INF/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.CardActionBean
>
> /home.action=com.somecompany.stripesprototype.web.recognition.CardActionBean
>
> /blahblah/blah.action=com.somecompany.stripesprototype.web.recognition.CardActionBean
>
>
>
>
>
>  ------------------------------
> *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 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

Reply via email to