On 12/11/07, Brian Pontarelli <[EMAIL PROTECTED]> wrote: > At first I thought this might be a problem because SmartURLs was > sub-classing the ActionConfig object in order to add some additional > information for performance reasons. However, I have a feeling that I > can remove the sub-class. All the same, I think your change still allows > sub-classing. Now I just need to figure out if I want to remove my > sub-class or not :)
Yeah, try to do it without the subclass, and feel free to add more builder methods as needed. > I've got some work done on the new convention plugin and put together a > short design doc for it because I kept getting lost in the soup of > conventions and configuration overrides. Here's the URL for the design doc: > > http://svn.apache.org/viewvc/struts/sandbox/trunk/struts2-convention-plugin/design.txt?view=markup Yep, looks fine to me. > With respect to allowed methods, the new plugin only generates > configuration for the execute method and any other method that is > annotated. So, with the new allowedMethods property inside the > ActionConfig, it should be a snap to just ensure that when the plugin is > constructing the ActionConfig instances it locks down the Action > accordingly. Cool. To be honest, I'm thinking that maybe the feature would be better simply as an Interceptor, and therefore, I might end up ripping it out this weekend. Doing it as an interceptor would certainly be the most flexible and consistent with how other features work. Don > > -bp > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
