> 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. Vadim > so currently only the debugging part remains. > > Serious question: Did anyone of you use this feature? > > Now, with one of the latest features of Cocoon, > the configurable pipelines, the concept of SAXConnectors > seems a little bit out of place. > For example if I want to use the debugging SAXConnector > for a particular request, it is only possible to turn on the > SAXConnector for the complete sitemap which slows down the > entire system. > > So, I currently see three possibilities: > > a) Deprecate the SAXConnectors and remove it asap. > b) Remove it now > c) Change the concept, so that it is possible to configure > the used SAXConnector on a map:pipeline base. > > If the SAXConnector concept is of value then we should go for c), > if not I'm +1 for b). > > Comments? > > Carsten > > Carsten Ziegeler Chief Architect Open Source Group, S&N AG > ------------------------------------------------------------------ > Cocoon Consulting, Training and Projects > ------------------------------------------------------------------ > mailto:[EMAIL PROTECTED] http://www.s-und-n.de > http://ziegeler.bei.t-online.de --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
