Interesting point!
Of course, what we do in the referenceInsert() operation can be viewed as a
variant of customized introspection (one in which there is an additional
method call at the end).
I guess we would have to provide access to the context in order for this
kind of thing to be possible. And there is the issue of how this kind of
thing will have to interact with our instrospection cache. And how to keep
the internals hidden from the user API.
I wouldn't want these to become some sort of open ended access to the
internals that removes any change of redesign in the future. It would need
very careful thought.
Jose Alberto
> -----Original Message-----
> From: Paulo Gaspar [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, April 11, 2001 11:11 AM
> To: [EMAIL PROTECTED]
> Subject: RE: EventCartridge
>
>
> Doesn't this sound as a nice place to place customized
> introspection too?
> =:o)
>
> Have fun,
> Paulo Gaspar
>
> > -----Original Message-----
> > From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On
> > Behalf Of Geir Magnusson Jr.
> >
> >
> > 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/
> >
>
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
