All that happens is that the ActionServlet calls init and destroy at the beginning and the end of the application's life cycle. (With the side-effect that the Action is loaded at start up instead of lazily.)
Since there aren't any parameters, it really isn't listening (or observing). It's just an investion-of-control technique so we can use an Action to manage resources instead of resorting to a separate servlet or other component.
So besides LifeCycleAction, the next best thing might be "AlphaOmegaAction" =:0) .. or SunRiseSunSet ... =:>
But unless there's a beta 4, I wouldn't bother changing it.
-T.
David Graham wrote:
I agree that PlugIn isn't an appropriate name. I think ActionServletListener would be more appropriate. Is it too late to change the name? If we wanted to match the various servlet listener interfaces we could define the init method as
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]>
-- 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]>
