cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylvain.wal...@anyware-tech.com>
Subject Re: [RT]: The value of SAXConnectors
Date Tue, 25 Jun 2002 17:23:24 GMT
Carsten Ziegeler wrote:

>Vadim Gritsenko wrote:
>  
>
>>>From: Carsten Ziegeler [mailto:cziegeler@s-und-n.de]
>>>
>>>Does anyone remember the good old SAXConnector?
>>>
>>>It was originally designed for transparently handling
>>>xinclude/cinclude statements. But it wasn't used for this
>>>because of the problems it caused for the caching.
>>>
>>>Then SAXConnectors were used for profiling and debugging.
>>>The profiling code was replaced by profiling pipelines,
>>>      
>>>
>>ProfilingSAXConnector is still there and the only place where time is
>>counted.
>>
>>You can refactor code so it is not needed... This could be possible to
>>do in Profiling*EventPipeline by inserting ProfilingTransformer
>>(transformer with functionality of ProfilingSAXConnector) between all
>>the stages of the pipeline when pipeline is assembled.
>>
>>    
>>
>Yes, exactly, or simply by inserting the current ProfilingSAXConnector 
>automagically between the components and nevertheless removing the
>SAXConnector support.
>  
>

What do you mean by "automagically" ? It's already automagic, since 
SAXConnectors are only used when they're declared in cocoon.xconf.

Also, I see a danger with Profiling*EventPipeline, because the "*" means 
combination with the various pipeline implementations : non-caching, 
caching, chache-point (no new from this one ?), etc.

I once (long ago) thought of a transformer that would check XML 
well-formedness of SAX events (for debugging custom transformers) and I 
now realize it would be a very good candidate for SAXConnector.

My opinion is to keep them (so option (c) of original post) and 
advertise them more, as they can be of real help during development, 
without having to tweak the sitemap.

While we're at development-time features : what about adding some 
location information when components are added to a pipeline ? 
TreeProcessor nodes know their location, and this may allow the display 
of more meaningfull information when an error arises during pipeline 
processing (e.g. "NullPointerException in transform at sitemap.xmap:341")

Thoughts ?

Sylvain

-- 
Sylvain Wallez
 Anyware Technologies                  Apache Cocoon
 http://www.anyware-tech.com           mailto:sylvain@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