Mailing-List: contact struts-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: struts-dev@jakarta.apache.org
Date: Sat, 7 Jul 2001 18:09:42 -0700 (PDT)
From: "Craig R. McClanahan" <craigmcc@apache.org>
To: struts-dev@jakarta.apache.org
Subject: Re: About extensons support mechanism...
In-Reply-To: <04da01c10748$bf777000$c77ba8c0@frmt1.sfba.home.com>
Message-ID: <Pine.BSF.4.21.0107071803160.98839-100000@localhost>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII


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