On Nov 20, 2007 7:11 PM, Brian Pontarelli <[EMAIL PROTECTED]> wrote: > I thought that this was not really the same. You couldn't map multiple > actions to a class or handle more different methods for actions. I > haven't looked at the codebehind in a long time, since I've been using > SmartURLs for 6 months or so.
You might try backporting something to see what you miss. I found that it was less than I expected :) > > Codebehind actually supports this now - struts.codebehind.pathPrefix - > > but I see it isn't documented. > > > True, but this is global and somewhat cumbersome with respect to slashes > (just a bug that annoyed me). SU handles this at the package, class and > global levels. I don't know what "cumbersome" means. If there's a bug, could we just fix it? I also don't know what is meant by SU handling this at the package, class, and global levels. > > I'm not so sure about this one. Would we do something like stripes > > where we scan for the 'actions' subpackage? I don't see the > > 'actionPackages' init parameter as too burdensome. > > > Yeah exactly. This is necessary to allow SU to find actions inside JAR > files in the classpath without requiring the action package for that JAR > file to be added to the configuration. Very nice in my opinion to be > able to drop a JAR file into a project and get a bunch of actions, > results, etc without any configuration. This is a must for me since > Vertigo and other projects use it heavily. > ... > Finding action classes and results from the classpath. For example, > Vertigo has an action named: Countries in a package named > org.inversoft.vertigo.struts.action; I map this to the URL > /vertigo/countries. You can execute this action from a JSP to build a > list of countries to use with a select box. Very cool. However, I have > to configure this action package in the struts XML or properties file or > use the current component.xml solution to inform SU that this package > exists. I think it would be better to just find all actions in packages > with specific names (like Stripes). That way I don't have any configuration. Then to what URI does "org.inversoft.vertigo.struts.action" map? > > I should also add, I don't see XML going away nor do I want it to. > > There will always be more things you can do in XML that you won't be > > able to do in annotations, and I see the codebehind plugin accepting > > this fact. I'd like it to add conventions and a few annotations to > > cover 90-95% of the cases, leaving more involved things like defining > > results, interceptors, and more complex package-level config to XML. > > > I'm on the other side of the fence. None of my apps to date have used > any XML at all. I prefer it this way and only use XML when I absolutely > have to. Well, there's external XML configuration for one-time customizations, and then there's external gluecode that we've been writing to cover each and every action When we eliminate glue-code, we eliminate work. But, whether one-time configurations take place in annotation or external XML is six-of-one, half-a-dozen of the other. Of course, with package-info.java, we should be able to have a full complement of both annotation and external configuration options. But, do we want to support mixing-and-matching both? If we have a full complement, would it be simpler to expect people to select one strategy per application? (The way JPA expects us to select one annotation strategy for columns - field or property.) > > Also, if I haven't mentioned it already, Struts 2.1 supports multiple > > filter instances in a webapp. This means you could have two filters, > > each looking for actions in a different root package and using > > different path prefixes for their results. I'm still not clear why > > you would be putting templates in two different root directories, but > > if you wanted to, you can. > > > This would be overkill with SU because you can handle multiple action > packages, multiple result locations, and most configuration with a > single filter. Obviously this might be helpful for some situations, but > I haven't found a need for it yet. > > > This is a great first step towards integrating the two plugins. > > Perhaps the next step, after some more discussion, would be to set up > > a matrix of the features SmartURLs has that codebehind doesn't, then > > we can systematically evaluate them in a way that is easy to follow > > and record. > > > I can put this together, but I'd like to finalize some decisions around > this stuff pretty soon. I think it is really just a matter of these last > 3-5 items and then just integration. One other point that hasn't been mentioned is the SEO conventions. I haven't tried, but I don't believe the CodeBehind converts camelCase to seo-case. A couple of general points: * Should configuration should follow an order of precedence, such as Convention, Annotation, and External (XML), where an External configuration would override any Annotation or Convention. Or, once we use Annotations, are the External action declarations ignored? (JPA style.) * Related question: If we add an ActionName annotation, should it block the other Convention or External bindings? Or, should it be added to the list, leaving other bindings intact? * It would be helpful if annotations were consistently designed to use smart-defaults and only require us to specify the attributes that change from the defaults. * Other aspects of the framework might be open to convention-based or annotation-based binding too, such as type converters. -Ted. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
