Jose Alberto Fernandez wrote:
>
> I like very much the ;concept of an EventCartridge, it gives a unified API
> for once. Actually I would like it to be more than just a container for
> handlers. I would it to be the one doing the work. That is move all the
> listener processing code to the EventCartridge.
>
> The advantage of doing this is that it allows providing diferent
> implementations, subclasses of EventCartridge that can be taylored to the
> particular applicartion, in particular in things related to chaining. I will
> try to attach some code of what I mean, but in principle what I am proposing
> is to define EventCartridge as follows:
No need for details :) It's a good idea, and pretty straightforward, I
think.
> public class EventCartridge
> implements NullReferenceEventHandler,
> NullSetEventHandler, ReferenceInsertionEventHandler {
>
> public boolean addEventHandler(EventHandler ev){...}
>
> /* Just for completion */
> public boolean removeEventHandler(EventHandler ev) {...}
>
> public final boolean attachToContext(Context context) {...}
>
> /* the methods of the handlers */
> }
>
> So, in the ASTNodes code the only thing we do is, for example:
>
> if (ec != null) localNullString = ec.nullReferenceRender(nullString);
>
> similar on the other calls. All the combining is delegated to inside the
> EventCartridge which can do whatever it needs to do. We can provide several
> implementation with different performance characteristics, if we want. Or
> just one that does everything for everybody. It becomes an orthogonal issue.
Yep.
> Now going to the chaining issue, if we follow the idea above, we can have a
> quick and simple EventCartridge that only stores one reference on each kind.
> For people that do not require more than that. And we can provide an
> EventCartridgeChainer close to what Geir has defined.
Or just punt the chaining idea - push it up to the application level.
(I like pushing to application level ;-> )
And if it turns out that people really need chaining, and are inventing
the wheel each time, we can just add it later.
> The attached patch just modifies the files on gier's whiteboard. I have not
> compile them. But they should give you an idea of what I have in mind.
I am going to combine these ideas, and put into the whiteboard. If no
yelps after we play with that, I will branch the CVS and add it (or what
it becomes) and the internal context support stuff as well.
Cool beans.
geir
--
Geir Magnusson Jr. [EMAIL PROTECTED]
Developing for the web? See http://jakarta.apache.org/velocity/
