> From: Sylvain Wallez [mailto:[EMAIL PROTECTED]] > > Carsten Ziegeler wrote: > > >Vadim Gritsenko wrote: > > > >>>From: Carsten Ziegeler [mailto:[EMAIL PROTECTED]] > >>> > >>>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.
Part of profiler's logic right now in SAXConnector, another part is in Profiling*EventPipeline. It is feasible to move all of the logic into Profiling*EventPipeline and remove connector, but nobody showed yet that the opposite is feasible. > 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. If you want to do this in every step of the pipeline - then yes. > 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. I'm either for (a) or (c), have no problem with any of these solutions. > 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") Sounds like fun :) Vadim > Thoughts ? > > Sylvain > > -- > Sylvain Wallez > Anyware Technologies Apache Cocoon > http://www.anyware-tech.com mailto:[EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
