> -----Original Message-----
> From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED]]
> Sent: Monday, March 18, 2002 11:54 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [RT] CallBack Style XML Handlers
>
> From: "Berin Loritsch" <[EMAIL PROTECTED]>
>
> > interface XMLSource
> > {
> > handle( ContentHandler ch, CallBackHandler cbh );
> >}
> >
> > interface XMLCallBack extends Command
> > {
> > XMLSource getFragment( Parameters paramList );
> >}
> >
> >interface CallBackHandler
> >{
> > XMLSource event( String type, Parameters paramList );
> >}
>
> I'm a bit slow maybe, but I don't see how these interfaces should call
> each
> other...
> Since I'm not familiar with the Excalibur event stuff, how would the
> call
> sequence be?
We start with the XMLSource. We give it a ContentHandler and a
CallBackHandler
Normal SAX events go directly to the ContentHandler, but when a
CallBackEvent is generated, it goes to the CallBackHandler. The
CallBackHandler resolves the "type" name with the specific XMLCallBack.
The CallBackHandler then executes the getFragment( Parameters params )
And returns the resulting XMLSource.
The original XMLSource then calls the handle() method on the embedded
Fragment. With in XInclude example, let us suppose we have the
Following scenario:
XMLSource [main]
{
handle( ContentHandler ch, CallBackHandler cb )
{
ch.startDocument();
ch.startElement( .... );
XMLSource included = cb.event( "xinclude", paramList );
Included.handle(ch, cb);
ch.endElement( .... );
ch.endDocument();
}
}
Internal to the CallBackHandler, we would have this:
CallBackHandler
{
event( String type, Parameters paramlist )
{
XMLCallBack callback = (XMLCallBack) m_eventTypes.get( type );
return callback.getFragment( paramlist );
}
}
> Another thing; here we have a Parameters object and a String being
> passed.
> From my experience in Swing editing stuff, where a lot of events go
> roung,
> it's best not to use Objects in callbacks, since this creates lots of
> object
> creation and garbage.
> As type we could use int, and an array of ints as parameters for
> example.
We already pass Parameters objects to all our Sitemap components. The
Weight of the Parameters is not heavy at all. We should be able to run
It without problems.
>
> > <call:event type="newsFlash">
> > <call:parameter name="example" value="Business"/>
> < </call:event>
>
> Hmmm... what about having other xml defined inside? How would that
> work out?
KISS (Keep It Simple Stupid)
By changing the internal markup to be XML, we would need to pass
Configuration objects instead of a simple parameters object. Most
Run-time customizations can be best handled with simple name/value
Pairs. Until we see a *real* need, I would rather stay away from
The arbitrary embedded XML approach. You were complaining about
The Parameters object before--the complexity of this would be worse,
For very little gain.
I am also thinking of simplicity of extending the CompiledXML spec.
> > Does this sound good as a starting point?
>
> If I ask a couple more questions like this, you're gonna come out with
> an
> implementation! ;-D
Awesome!
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
