But wouldn't a true notion of a PlugIn like I tried to mention in my earlier mail be useful as well. Let me take a concreete example and let's for a brief moment forget that there is any existing plug-in in the servlet framework. For typical applications one can immediately see that there might be a requirement to:
1. Do a central authentication check on a mojority of requests 2. May be a central authorization check on a majority or requests 3. A parameter validation check on almost every request 4. May be a externalized business rule check on a group of requests 5. May be a dynamic context building on every request (on the basis of which let's say you want to choose appropriate look and feel or personalization or the presentation components aggregation to display, whatever) 6. May be do audit trail on every authenticated and authorized request in a central transparent manner Now the easiest single way probably would be to have a true notion of PlugIn implemented into my Struts framework so that I can on some basis (may be URI, may be some convention of mine or whatever) easily sequence the plug-in set and order in which I want certain things to happen (and even synchronicity of the way I want that action to take place Eg. May be I want Audit trail to happen in an asynchronous manner by an audit event exported out to an external message queue). I think it will probably be easiest to implement using an Event and a Listener kinda pattern where the PlugIns say implements a StrutsRequestEventListener which say has a method like handleEvent and takes in a StrutsRequestEvent. Additionally the Controller has registerPlugIn kinda API which is used by the init interface of the PlugIn implementation to register itself with the Controller, and additionally there is a PlugInConfigurator which goes thru a centralized across plug-in configuration file maybe and registers the contexts (URI or some convention of the installation or whatever) against the plugin sequence and there you are all set to have kinda all the 6 points above transparently and contextually coming into picture for every request coming on to my struts installation. Baltimore SelectAccess or Netegrity SiteMinder can build a Authenticator and Authorizer plugin for Struts rather than for Apache or IIS ;-) cheers, pdhoolia -----Original Message----- From: Ted Husted [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 16, 2003 4:46 PM To: Struts Developers List Subject: Re: PlugIn model design The monicker PlugIn as used in Struts 1.1 beta seems like a bit of a misnomer to me. As I understand it, the PlugIn interface gives an Action init and destroy methods so it can load and dispose of external resources. This is mainly as an alternative to loading a seperate servlet to do the same. We probably should have used a less sexy name, like LifeCycleAction. There's a lot of things you could use this for without touching the RequestProcessor. If Struts supports the idea of a "PlugIn", I think it would really be through Application Modules. The idea being you could have an "User Account Module" that you could plug into your application, so you wouldn't have to write your own. Jetspeed calls these sort of things "portlets". So, the idea is that you could unzip a module into your existing application directory, and then plug it into your Struts application through the Struts config. The RequestProcessor also lets you plugin a replacement, in case you need to do something very fancy, like process tiles as part of the request/response. You can replace the default RequestProcess, or give one to each module. The idea being one module might use somethign like tiles, while the other modules don't. As point in fact, all of the Struts objects accept plug-ins replacements. You can plug-in your own ActionForwards, ActionForms, and so forth. Now, I suppose you could call Tiles a plugin too. But Tiles is really a RequestProcessor. It uses a PlugIn action to load the Tiles definitions, but I think that is more of a necessary evil than a deliberate design. If the framework let you load arbitrary configuration files, Tiles wouldn't need a PlugIn Action at all, it would just subclass the RequestProcessor. Initially, Cedric tried loading the RequestProcessor and the Tiles (PlugIn) Action separately, but it wasn't working, so as a workaround he used the Tiles PlugIn Action to bootstrap the Tiles RequestProcessor, but I don't think that is how the procedure was originally envisioned. -T. Pankaj Dhoolia wrote: > Hey guys, > > My earlier message appears in a slightly screwed up manner probably > because of digital signature. So resending without it. Sorry for the > trouble. > > Just wanted to discuss the design of the PlugIn model a bit. It seems > to me that the notion of plugin is not truely a plugin. The reason why > I say that is as follows. Let's say there are 3 guys who are > independently developing real cool plugins for Struts using the PlugIn > model and I as a consumer realize that I could use all the 3 sequenced > in a particular manner. Well will I be able to do it. I think the > answer is "no", and the reason for that is that rather than the PlugIn > subscribing to a generic ProcessorEvent which the Controller could > pass to the subscribing plugins in a generic manner, the current > mechanism requires the Plugins to subclass the RequestProcessor class > to do the same. So in the example above the three guys building 3 > independent plugins would be building independent subclasses for the > RequestProcessor also (which will required to be set as the > processorClass for the controller). This makes my job as a consumer of > all three plugins very difficult. > > Now lets analyze an alternate design in which there is just a single > RequestProcessor that the controller deals with but PlugIn are > registered with the Controller, against (say) a set of URIs, and that > the controller looks at this configuration (which is essentially a > registered sequence of PlugIns against that URI), and invokes the > PlugIns in that order. We could even define a simple configuration > option thru which the PlugIns can plug-in in a synchronous or > asynchronous manner, into the Struts base flow. That is we can have > the plugins registered against a URI (say) registered as 1st plugin > (synchronous), second plugin (asynchronous), and the third PlugIn > synchronous, and the Controller can accordingly deal with it. > > Let me know your thoughts. > > cheers, > pdhoolia > -- Ted Husted, Struts in Action <http://husted.com/struts/book.html> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
