Hello Roland,
Comments below..
Thursday, July 05, 2001, 2:54:54 PM, you wrote:
RH> 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.
RH> Instead of a "Service" _interface_ I suggest a a Service base class
RH> with no-op implementations for the plugin hooks. This would make a
RH> possible late upgrade of the plugin contract much easier, since it
RH> won't break existing code.
Why? Abstract class Service can only encapsulate some class with
service logic or with some kind of bridge to ready to use component.
In case of interface we can take ready solution and extend it with
Service interface implementation. And more - we can write blank
Service and encapsulate external logic to it too.
>> 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?
RH> I think the first solution is more preferable, since you have only one
RH> kind of plugin defined by one interface (or base class).
RH> If you would like to differentiate between different kind of plugins
RH> different kind of interfaces (or base classes) like InitService and
RH> ProcessService might provide the extra flexibility to selectively call
RH> only the appropriate plugin at certain hooks (and a plugin only needs
RH> to implement the service interface (extend service base class) it is
RH> interested in. (Well, in this scenario, interfaces are probably better
RH> suited than base classes, since a plugin could implement several
RH> interfaces at once but not extend more than one base class).
Yes, of course. It is main reason to interfaces - take a look to the
event model... And one question about it - may be event/listener terms
will be better than Xservice/member?
--
Best regards,
Oleg mailto:[EMAIL PROTECTED]
