Once the branch is available, I can also try it against the JPA MailReader that's in the sandbox. This particular application was reworked for SmartURLs and the backported to CodeBehind. Bringing it forward again would help test whether the branch is a proper superset of the existing feature set or not.
Just committing it to the sandbox under the name CodeBehind2 might be a good way to go, since that is how we usually bring plugins and whatnot into the project. -Ted. On Dec 6, 2007 5:03 AM, Don Brown <[EMAIL PROTECTED]> wrote: > Could you commit your version as a development branch, rather than to > trunk? I'm using/improving Codebehind right now in some of the new > features both in core and the rest plugin. I'd also like a chance to > fully review the changes before we dump the old. > > On 12/6/07, Brian Pontarelli <[EMAIL PROTECTED]> wrote: > > I'm going to start working on the SmartURLs port. Here's what I'm planning: > > > > 1. Deprecate all the current codebehind annotations and classes > > I'm still not convinced this is a good idea, but as I said, I'll > reserve judgment till the merge branch is ready. > > > 2. Create a new package named org.apache.struts2.plugin.codebehind > > Use org.apache.struts2.codebehind, as it fits better with the > convention used by other plugins. > > > 8. Add configuration for changing the names used to find action packages > > via configuration property struts.plugin.codebehind.actionPackage.names > > > > 9. Add support for action package exclusions via configuration property > > struts.plugin.codebehind.actionPackage.excludes > > Regarding 8 and 9, I recommend simplifying the name as much as > possible, mainly because properties can alternatively be declared in > web.xml as init-params, which I've been finding more convenient > lately. > > > 10. Remove ActionNames and ActionName in favor of a new Action > > annotation for methods (not sure about this yet) > > > > 11. Remove Namespace annotation (this should probably be handled > > entirely in the action annotations) > > I still think we need to keep the idea of changing a namespace for all > actions in a package. The package-info.java suggestion seems perfect. > Same goes for specifying parent packages. > > Thanks for taking this on, and I'm looking forward to finally > "finishing" this plugin :) > > Don --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
