cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Berin Loritsch" <blorit...@apache.org>
Subject RE: [RT] CallBack Style XML Handlers
Date Mon, 18 Mar 2002 17:25:10 GMT


> -----Original Message-----
> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
> Sent: Monday, March 18, 2002 11:54 AM
> To: cocoon-dev@xml.apache.org
> Subject: Re: [RT] CallBack Style XML Handlers
> 
> From: "Berin Loritsch" <bloritsch@apache.org>
> 
> > 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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message