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
