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 Tue, 19 Mar 2002 13:47:19 GMT
> I maybe a bit too agressive here, so please let me know if so:
> 
> Can the caching logic be shifted up one step above the 
> CallBackHandler? How about a Cacheable CallBackHandlerInterface
> 
> interface CacheableCallBackHandler
>   {
>   boolean hasChanged( String type, Parameters paramList );
>   XMLSource event( String type, Parameters paramList );
>   }
> 


This is not ThreadSafe.  Not to meantion, the caching implementation
Can and should be handled inside the CallBackHandler.  The item will
Resolve to a cached XMLSource, so we have the same effect without the
Unnecessary complexities of shifting this logic to the user classes.
IMNSHO, a cache should be as invisible as you can possibly make it.

This is one step to enable that to happen.
<snip/>


> 
> From your email:
> >  It is important to preserve the order of the callback 
> events, but not 
> >necessarily when they are first called.  For instance, we 
> can choose to 
> >execute the callbacks when we first resolve the source. We 
> must include 
> >the results at the location where they are needed.
> 
> It would be really cool if an XMLSource (which is otherwise
> static/cacheable) can somehow iterate before starting to fire 
> events through its callback segments and if they all haven't 
> changed then the whole XMLSource can report that it hasn't 
> changed, thus the next transformation can be skipped.

Exactamundo.  Now your getting it!  


> Maybe another modification of the code above (although I 
> don't quite understand yet  the current caching mechanism ):
> 
> XMLSource [main]
> {
> 
>     boolean hasChanged()
>       {
>       iterate over callback elements and if none has changed 
> then return true, so that the whole document is pulled from the cache
>       otherwise return false
>       }
> 
>     // if some of the callback handlers HAS changed though, 
> we'll still need to do this
>     handle( ContentHandler ch, CallBackHandler cb )
>     {
>         ch.startDocument();
>         ch.startElement( .... );
> 
>         XMLSource included;
>         if ( cb.hasChanged("xinclude", paramList) )
>           {
>           included = cb.event( "xinclude", paramList );
>           }
>         else
>           {
>           included = pullOutFromCache();
>           }
> 
>         Included.handle(ch, cb);
> 
>         ch.endElement( .... );
>         ch.endDocument();
>     }
> }

I would not do that.  The purpose of the XMLSource and the
Callback system is to allow caching fragments of the document,
And letting those cached fragments usable in multiple documents.
By not poluting the cached XMLSource document, we can effectively
Not have to have a new entry for each fully resolved document.

We are dealing with SAX fragments, so the cost of assembling
A larger document from smaller pieces is essentially zero.

> 
> 
> > The first thing we need to do is put the interfaces (after 
> we agree on
> > Them) into CVS.  As a starting point, we can automagically convert 
> > XInclude directives into XMLCallBack events.  That way, we 
> don't need 
> > a separate transformer, and include operations that would 
> normally be 
> > expensive can be made quick and painless.
> >
> > Once we have the XInclude set in place, we can take advantage of a 
> > small cache size, and look into converting other pieces over to the 
> > policy as well.
> >
> > Does this sound good as a starting point?
> 
> 
> You bet it does !
> 
> 
> Ivelin
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message