Craig could you explain a little more about ........" to *modify* what
happens next? For example, let's say you wanted to implement "is the user
logged on?" checking as an event listener. How would the listener indicate
back to the framework that the request should be redirected to the logon
page?......"
I dont understand the problem completely
----- Original Message -----
From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, July 07, 2001 9:09 PM
Subject: Re: About extensons support mechanism...
>
>
> 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.
> >
>
> I think the two concepts are related as well. "Extensions" would be a
> 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.
> >
>
> Another issue (and, frankly, the reason that I didn't include an
> event/listener model earlier) is more complex -- what if a listener wants
> to *modify* what happens next? For example, let's say you wanted to
> implement "is the user logged on?" checking as an event listener. How
> would the listener indicate back to the framework that the request should
> be redirected to the logon page?
>
> One fairly radical idea I've considered is to not use events for this
> purpose, but to treat the basic processing that the controller servlet
> itself does as a workflow that can be scripted. That way, you could (in
> effect) insert your own "processXxxx" type functions anyplace you like in
> the standard workflow. Presumably, the scripting language for the
> workflow would have mechanisms to support conditional processing to deal
> with my question above.
>
> Given that, an event/listener model that merely notifies application logic
> about things that are happening is still useful -- it's just not going to
> be called on to serve this purpose.
>
> > --
> > Martin Cooper
> >
>
> Craig
>
