I guess we have been looking at different issues on these matter.
I was looking at how to make the framework as simple and efficient as
possible from the execution point of view. That is why I am concern on how
the EventCartridge and the nodes deal with event notification (I mistakenly
refered to the Context instead of the nodes). And why things like typeing
seem like important to me.
On your side, I think you were more concern on having a stable general API
for the users to use.
I guess our concerns complement each other. I will take a look at what you
are proposing before making more comments.
Jose Alberto
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
> Behalf Of Geir Magnusson Jr.
> Sent: Sunday, April 08, 2001 1:50 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [PROPOSAL] InsertionListener + [VOTE]
>
>
> Jose Alberto Fernandez wrote:
> >
> > OK Geir,
> >
> > I took a look at your code and I gained no information what
> so ever on what
> > you are proposing. I guess I am looking in the wrong place.
>
> I guess. I thought the code would have helped. :)
>
> Start with the EventCartridge class. That should help you understand
> the basics of having a set of related handlers, organized separately
> from the basic Context. That's really the crux of what I am
> suggesting.
>
> > The classes in the whiteboard just provide some interfaces
> and a structure
> > that contains references to these interfaces. And they are
> not even strongly
> > typed.
>
> That's right, and that can be cleaned up, of course. This is just a
> sketch. I figure someone would get bugged by the
> type-checking approach,
> but wouldn't have guessed it would be a Java programmer :)
>
> >
> > Can you tell me where is the code that calls the methods in
> EventCartridge?
>
> The nodes, and I didn't check that into the whiteboard, because my
> concern here was the discussion about the structure and
> extensibility of
> the application API. I believe we don't want to dangle arbitrary and
> random things off of the context.
>
> But the node implementation is important stuff too - the nodal
> implementations are pretty straightforward, and I am happy to check
> those in as well. To me, those were less important as we can improve
> those over time, whereas as we commit to a user API, we don't want to
> change that.
>
> Just note this is something I have just been scratching around with -
> so things aren't perfect. Lets get a handle on the basic idea, and we
> can quibble about the minutea later...
>
> > What does it mean to have a chain of Listeners for these events?
>
> Simply that you can register more than one, and have the
> results of one
> passed to the next.
>
> That idea prollie won't apply to many of them, if we decide to keep it
> at all, as it doesn't seem to
> make sense for all of them, but it seems like a nice feature. On the
> other hand, it may really stink. I think we'll figure that out by
> playing with it.
>
> > If I have several NullReferenceEventHandlers installed, what
> > is the semantics of that?
>
> Not really sure - I figured the node might just call down the line,
> passing the results of one call to the next if appropriate
> (which would
> be the case for reference insertions editors). In the case
> of something
> which is boolean, than maybe the semantics are the first veto 'wins'.
> Something like that.
>
> It's clear the semantics will be different per event handler.
>
> A user of these listeners isn't required to use chaining.
> You can make
> the handler routine as rich as you want.
>
> > What is the context going to do?
>
> The context isn't going to do anything, just deliver the
> 'EventCartridge'. That's the point here - the context stays out of
> it. Only the AST nodes do the work.
>
> > Same for the others? Why is that semantics better than any
> other a user may
> > want?
>
> I am not sure what you mean. I don't think I have made any claims to
> the superiority of one set of semantics over another. Just
> showing what
> I have been thinking about and playing with for a little while that
> would solve other problems, and how it dovetails nicely with the whole
> 'reference insert' XML escaping issue.
>
> The user is capable of doing whatever they want. We have to
> set up some
> semantics for how these work - but since the user writes the event
> handler, if there is some new semantic behavior, they should
> just ignore
> the chain idea, and do something themselves... pretty straightforward.
>
> Remember, there isn't anything 'global' about this - there is no
> collision, collusion or interaction between the event handlers of
> different users/threads.
>
> >
> > You mentioned that we can define more event handlers as needed?
>
> Of course. We have only identified a small handful right now. I am
> sure more will come down the line. If they are indeed really
> cheap, and
> there is no penalty overall, why not?
>
> > You are
> > still needing to change the engine everytime you add a new
> type of event,
> > aren't you?
>
> Of course. There is no magic.
>
> > I guess what you mean is that the user API does not need to
> > change on each addition, is that what you meant?
>
> Yes. I think that's important. Not many people enjoy having diddle
> with their code and iteratively recompiling on each new minor release,
> especially in a production environment. It would be nice if we could
> add them as we find the need w/o affecting users.
>
> >
> > Anyway, if you can point me to where the firing mechanism
> for the events is
> > located I will get a better understanding of all these.
>
> Ok. Will check that stuff in too.
>
>
> geir
> --
> Geir Magnusson Jr. [EMAIL PROTECTED]
> Developing for the web? See http://jakarta.apache.org/velocity/
>
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
