init(ActionServletEvent e).
It's not a big deal but PlugIn is quite misleading.
David
From: Ted Husted <[EMAIL PROTECTED]>
Reply-To: "Struts Developers List" <[EMAIL PROTECTED]>
To: Struts Developers List <[EMAIL PROTECTED]>
Subject: Re: PlugIn model design
Date: Thu, 16 Jan 2003 16:45:49 -0500
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]>
_________________________________________________________________
Help STOP SPAM: Try the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
