You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Gopal Venkata Achi <Go...@igate.com> on 2003/12/11 19:13:40 UTC

PlugIn Interface implementation

Hi All,
 
Has anyone experienced with PlugIn interface implementation?
We are thinking of abstracting the service calls from the action class and creating the service layer which implements PlugIn.  
Please suggest me on what is the advantage that we get by implementing this PlugIn, and is this PlugIn is a kind of marker interface, does it allow me to create different methods while implementing?
In implementing class, what are all objects that we have access to?
 
I appreciate any help/suggestions in this regard.
 
Regards,
Gopal
 

Re: PlugIn Interface implementation

Posted by Ted Husted <hu...@apache.org>.
The purpose of the plugin interface is to give people a chance to 
initialize their own resources without subclassing ActionServlet or 
creating their own.

Typically, you would not use the PlugIn class directly, but whatever 
resources it initialized (and then placed in Application scope under a 
known name).

In any event, you should definately remove any service methods from the 
Action class and place these on some other object. A very good candidate 
for a service layer is the Chain of Command package, now in the Jakarta 
  Commons Sandbox. Another likely suspect is HiveMind (also in the 
Sandbox).

HTH, Ted.

Gopal Venkata Achi wrote:
> Hi All,
>  
> Has anyone experienced with PlugIn interface implementation?
> We are thinking of abstracting the service calls from the action class and creating the service layer which implements PlugIn.  
> Please suggest me on what is the advantage that we get by implementing this PlugIn, and is this PlugIn is a kind of marker interface, does it allow me to create different methods while implementing?
> In implementing class, what are all objects that we have access to?
>  
> I appreciate any help/suggestions in this regard.
>  
> Regards,
> Gopal
>  
> 
> 
> ------------------------------------------------------------------------
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-user-help@jakarta.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org