> 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.
I think this is a perfect candidate for the event/listener framework. The
key is to decide what the interesting events are. This needs to be done
outside the context of the current implementation as much as possible.
What I mean by that is that we should not be looking at the code and saying
"oh, there's an interesting method I'd like to hook into" so much as
thinking "ah, it would be interesting to be told when this is about to
happen or that has finished happening". If the code ends up needing some
restructuring to accommodate that, then we should go ahead and make those
changes.
If we only look at the current implementation, then we will be looking with
blinders on. There is a much greater risk that we will hinder the
development of later extensions, by looking at what we have instead of
thinking about what we really want.
--
Martin Cooper
----- Original Message -----
From: "Ron Smith" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, July 04, 2001 6:18 AM
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]
>
