RE: PlugIn model design

[James Higginbotham <jh...@betweenmarkets.com>]

It just sounds like a good candidate for the interceptor pattern,
allowing each "plugin" to registry an interceptor in th request
processing chain. Its up to the RequestInterceptor to then determine if
the current request is a valid request to do its work in. For instance,
I have added an internal concept of a WizardAction to our codebase. For
simplicity sake, i check to see if the input="wizard" so that I can
return the proper JSP when a validatione error occurs, without having
indiv mappings for each step. I had to subclass the default RP, but if I
choose to start using Tiles, I need to move my code over to the Tiles RP
subclass instead. Having an RequestInterceptor allows me to check in the
processValidate() whether my custom logic is even appropriate or not..
URI mapping may be one way, parameters ina  request may be another. 
 
Thoughts?

	-----Original Message-----
	From: Pankaj Dhoolia [mailto:pdhoolia@hotmail.com] 
	Sent: Thursday, January 16, 2003 2:41 PM
	To: struts-dev@jakarta.apache.org
	Subject: PlugIn model design
	
	
	Hey guys,
	 
	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