Let us know how overriding the default stack turns out. In other plugins, I've been creating new stacks, then assuming a user would just use that stack. Also, I'd make that stack the default stack in the plugin package, something like myplugin-default, so that if a user extended it, my stack would be the one they'd get. I generally assume that for any sizable, production application, you should construct your own stack with exactly the interceptors you need, but I could be wrong.
Anyways, I've been thinking of ways to plug interceptors from plugins into the default stack so the user doesn't have to lift a finger, so if you have any ideas, send them along. Don On 10/11/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Rock on my brother! And however did you guess that it might be a breadcrumb > plugin? :) Karin has been patiently waiting to see code, so I finished it > this morning at 3:00 AM around watering my lawn (with a flashlight) and > making coffee! By noon today I was too tired to workout the > stuts-plugin.xml details. So are you suggesting my defaultStack > implementation *will* override the one in struts-core.xxx.jar? I saw the > order they are applied but wondered if there was a qualifier <ns?> beyond > the simple name. The implementation of this plugin does not require > interfaces to use. It is parameter driven and easily configured at the > interceptor declaration itself. I am really liking this framework. > > Scott > > On 10/10/07, Wes Wannemacher <[EMAIL PROTECTED]> wrote: > > > > Scott, > > > > I would say that you are okay overriding the defaultStack since it is > > a plugin. For a user to actively install your plugin, then they are > > seeking the functionality you are providing. I don't know much about > > the plugin you are writing, but if it works similar to other > > interceptors, meaning that the user has to implement an interface to > > get the functionality (like, if you were building a breadcrumb plugin > > and actions have to implement com.gmail.stanlick.Crumbable, or have to > > annotated by @com.gmail.stanlick.Crumb), then it should have no > > side-effects. The advantage of overriding the defaultStack is that > > most users will have less steps to be up and running, but the caveat > > is that users who don't use defaultStack will have to include your > > interceptor manually. Of course, you'll have all of this documented > > and users in the second scenario will most likely know where to look > > to get your plugin up and running. > > > > -W > > > > On 10/10/07, stanlick <[EMAIL PROTECTED]> wrote: > > > > > > I am writing a plugin that consists of a new interceptor. I would like > > its > > > struts-plugin.xml to append to the defaultStack so the interceptor works > > out > > > of the box for packages leveraging the default interceptor stack. What > > is > > > the ethical thing to do as it relates to a plugin modifying the default > > > interceptor stack? Overriding the stack does not pass the tummy test, > > but > > > in the spirit of plugin drop-n-go, I also feel odd about including a > > list of > > > modifications you need to make to get the plugin to play! > > > > > > Scott > > > -- > > > View this message in context: > > http://www.nabble.com/Struts-2-Plugin-tf4603263.html#a13143714 > > > Sent from the Struts - User mailing list archive at Nabble.com. > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > -- > > Wesley Wannemacher > > President, Head Engineer/Consultant > > WanTii, Inc. > > http://www.wantii.com > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > Scott > [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
