Oleg V Alexeev <[EMAIL PROTECTED]> writes:
> ServiceServlet work on idea - developer can register unlimited
> number of services in struts-config, each service is a java class
> based on Service interface, each service can be subscribed to any
> processing point, such as - init, destroy, initDigester,
> processPreprocess, processPopulateBefore, processPopulateAfter,
> processValidateBefore, processValidateAfter. ServiceServlet iterate
> via list of subscriptions at every processing point and call
> appropriate method from service.
Instead of a "Service" _interface_ I suggest a a Service base class
with no-op implementations for the plugin hooks. This would make a
possible late upgrade of the plugin contract much easier, since it
won't break existing code.
> My question is - what way is the best to serve processing points
> listed above? Now I create FastArrayList instances for every
> subscription list and all manipulations with subscriptions
> (register, get iterator via subscriptions, drop, etc.) are made with
> help of separate method -
>
> registerInitMember( Service service, int order ) {}
> regisetrInitDigesterMember( Service service, int order ) {}
> ....
>
> May be such solution would be more flexible? -
> registerMember( Service service, int order, String pointName ) {
> //find ArrayList of subscriptions for such pointName
> //register service at ArrayList
> }
>
> Hard coded solution is more reliable, but time consume and not
> flexible. But more flexible solution, with search for appropriate
> subscription, is slow for my mind. What way is the best?
I think the first solution is more preferable, since you have only one
kind of plugin defined by one interface (or base class).
If you would like to differentiate between different kind of plugins
different kind of interfaces (or base classes) like InitService and
ProcessService might provide the extra flexibility to selectively call
only the appropriate plugin at certain hooks (and a plugin only needs
to implement the service interface (extend service base class) it is
interested in. (Well, in this scenario, interfaces are probably better
suited than base classes, since a plugin could implement several
interfaces at once but not extend more than one base class).
--
...roland huss
consol.de