Hello Martin,
Sunday, July 08, 2001, 4:55:56 AM, you wrote:
>> Is what I describe above within the scope of the event/listener
>> todo for 1.1? I thought it might be, which is why I said
>> I was interested in tying the Extensions package into
>> the event/listener model work.
MC> I think this is a perfect candidate for the event/listener framework. The
MC> key is to decide what the interesting events are. This needs to be done
MC> outside the context of the current implementation as much as possible.
MC> What I mean by that is that we should not be looking at the code and saying
MC> "oh, there's an interesting method I'd like to hook into" so much as
MC> thinking "ah, it would be interesting to be told when this is about to
MC> happen or that has finished happening". If the code ends up needing some
MC> restructuring to accommodate that, then we should go ahead and make those
MC> changes.
MC> If we only look at the current implementation, then we will be looking with
MC> blinders on. There is a much greater risk that we will hinder the
MC> development of later extensions, by looking at what we have instead of
MC> thinking about what we really want.
Yes. Now I try implement first edition of such ServicesServlet in base
of ActionServlet code and insert calls to the Services to the main
(for my mind) processing points. I not venture to make core
refactoring of ActionServlet - I only insert calls to the external
services to the processPreprocess(), processValidate(), etc.
MC> --
MC> Martin Cooper
MC> ----- Original Message -----
MC> From: "Ron Smith" <[EMAIL PROTECTED]>
MC> To: <[EMAIL PROTECTED]>
MC> Sent: Wednesday, July 04, 2001 6:18 AM
MC> Subject: Re: About extensons support mechanism...
>>
>> When I created the ExtensionsServlet (I assume ServicesServlet
>> takes its place here), I stopped short after the
>> init(), destroy(), and initDigester() methods because I had
>> a feeling that we might want to handle extending the other
>> methods using a different mechanism.
>> I see init, destroy, and initDigester methods as basic
>> lifecycle methods that most/all extensions/services would want
>> to tap into.
>> When getting into the process() type of methods, I could see
>> many extensions would want to tap into one or more of these methods,
>> but why limit it to the ActionServlet class? An extension may want
>> to be able to tap into points in processing of other classes, such
>> as an action class or forward class. From looking at the code it seems
>> like most processing is going on in the ActionServlet, but
>> my gut feel is that some extensions will need to extend processing
>> points in other classes besides ActionServlet - it's just one class
>> in an application framework after all.
>>
>> For this, I think something like your second solution with a more
>> centralized event dispatcher/queue would be needed. The listeners
>> (services) would register interest in an event with a central
>> dispatcher. When the ActionServlet (or whatever class is generating
>> the events) gets to one of these points in processing, like
>> processPopulateBefore(), it would fire off an event to the central
>> dispatcher which would immediately notify the listeners registered
>> for that event type.
>> So the listeners are decoupled from the class generating the
>> events (e.g. ActionServlet). Heck, the object generating the
>> event doesn't even have to exist for the listener to be able to
>> register interest in the event it generates (which is probably necessary
>> to trap events from classes like Action and ActionForward).
>>
>> Is what I describe above within the scope of the event/listener
>> todo for 1.1? I thought it might be, which is why I said
>> I was interested in tying the Extensions package into
>> the event/listener model work.
>>
>> So my two cents is I'd like to generalize the listener/event/dispatch
>> mechanism and to support listening to classes beyond ActionServlet.
>>
>>
>> Oleg V Alexeev wrote:
>> >
>> > Hello struts-dev,
>> >
>> > This evening I end up druft of ServicesServlet - extended version of
>> > ActionServlet with support of pluggable services (extensions in old
>> > terms). I puzzle over architectural question about ServicesServlet
>> > and may be anybody can suggest me right way...
>> >
>> > 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.
>> >
>> > 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?
>> >
>> >
>> > --
>> > Best regards,
>> > Oleg mailto:[EMAIL PROTECTED]
>>
--
Best regards,
Oleg mailto:[EMAIL PROTECTED]
