You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Carsten Ziegeler <cz...@s-und-n.de> on 2002/06/25 12:23:16 UTC
[RT]: The value of SAXConnectors
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,
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:cziegeler@s-und-n.de http://www.s-und-n.de
http://ziegeler.bei.t-online.de
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [RT]: The value of SAXConnectors
Posted by Vadim Gritsenko <va...@verizon.net>.
> From: Sylvain Wallez [mailto:sylvain.wallez@anyware-tech.com]
>
> 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.
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:sylvain@apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT]: The value of SAXConnectors
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
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
RE: [RT]: The value of SAXConnectors
Posted by Vadim Gritsenko <va...@verizon.net>.
> From: Carsten Ziegeler [mailto:cziegeler@s-und-n.de]
>
>
> 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.
+1
:)
Vadim
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [RT]: The value of SAXConnectors
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
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.
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [RT]: The value of SAXConnectors
Posted by Vadim Gritsenko <va...@verizon.net>.
> 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.
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:cziegeler@s-und-n.de http://www.s-und-n.de
> http://ziegeler.bei.t-online.de
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org