David
From: "Pankaj Dhoolia" <[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 17:15:56 -0500
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]>
_________________________________________________________________
The new MSN 8 is here: Try it free* for 2 months http://join.msn.com/?page=dept/dialup
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
