Hello Craig,
Sunday, July 08, 2001, 5:09:42 AM, you wrote:
CRM> On Sat, 7 Jul 2001, Martin Cooper 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.
>>
>> 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.
>>
CRM> I think the two concepts are related as well. "Extensions" would be a
CRM> perfectly natural way to configure your listeners.
>> 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.
>>
CRM> Another issue (and, frankly, the reason that I didn't include an
CRM> event/listener model earlier) is more complex -- what if a listener wants
CRM> to *modify* what happens next? For example, let's say you wanted to
CRM> implement "is the user logged on?" checking as an event listener. How
CRM> would the listener indicate back to the framework that the request should
CRM> be redirected to the logon page?
I think it must be defined in ActionServlet code. Call to the external
service can return result and ActionServlet make solution on base of
it. And more - service method itself can take request object, do
redirect to the logon page and return false as for processPreprocess.
CRM> One fairly radical idea I've considered is to not use events for this
CRM> purpose, but to treat the basic processing that the controller servlet
CRM> itself does as a workflow that can be scripted. That way, you could (in
CRM> effect) insert your own "processXxxx" type functions anyplace you like in
CRM> the standard workflow. Presumably, the scripting language for the
CRM> workflow would have mechanisms to support conditional processing to deal
CRM> with my question above.
Great! But in first iteration I want to lay the foundation of
ServicesManager. But now another idea worry my mind... 8) All logic of
ActionServlet can be build on base of Services approach... With
scripting, workflow support, etc. I agree with you.
CRM> Given that, an event/listener model that merely notifies application logic
CRM> about things that are happening is still useful -- it's just not going to
CRM> be called on to serve this purpose.
--
Best regards,
Oleg mailto:[EMAIL PROTECTED]
