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/
