You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Torsten Curdt <tc...@dff.st> on 2001/07/22 12:02:21 UTC
xsp.xsl
Are there reasons or objections not to change
the access to the contenthandler in the xsp.xsl
from "this.contentHandler" to only "contentHandler"?
Then we could do a local redirect of SAX events:
...
contentHandler.startElement("", "item", "item", xspAttr);
{
AttributesImpl xspAttr = new AttributesImpl();
XMLConsumer contentHandler = ...;
contentHandler.startElement("", "item", "item", xspAttr);
}
It gives us the feature of redirecting SAX events
to other XMLConsumers. (This would be a real seamless
integration for the XForm and DOMObject implementation)
There should be no undesired side effects...
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: xsp.xsl
Posted by Torsten Curdt <tc...@dff.st>.
> > > Yes, there are side effects with logicsheets that use
> > > this.contentHandler.
> >
> > Then we make them not to use it, too ;)
> >
> > > I use the following construct to change the contentHandler :
> > > <xsp:logic>
> > > ContentHandler oldHandler = this.contentHandler;
> > > try {
> > > this.contentHandler = otherHandler;
> > > ...
> > > } finally {
> > > this.contentHandler = oldHandler;
> > > }
> > > </xsp:logic>
> >
> > ...I was just not sure if changing the contentHandler in
> > a multi thread environment is a good idea...
> >
> > ..but if this is really ok - I'm also fine with that!
> > (Although a simple search and replace over logicsheets
> > should be a bit cleaner - don't you think?)
> >
> Unfortunately, search/replace won't be enough : some complex logicsheets
> (e.g. esql.xsl) split the generated code in sub-methods or inner
> classes. This would require more changes in these.
Well, anyway.. I am fine with your way :)
Thanks
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: xsp.xsl
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Torsten Curdt a écrit :
>
> > Torsten Curdt a écrit :
> > >
> > > Are there reasons or objections not to change
> > > the access to the contenthandler in the xsp.xsl
> > > from "this.contentHandler" to only "contentHandler"?
> > >
> > > Then we could do a local redirect of SAX events:
> > >
> > > ...
> > > contentHandler.startElement("", "item", "item", xspAttr);
> > > {
> > > AttributesImpl xspAttr = new AttributesImpl();
> > > XMLConsumer contentHandler = ...;
> > >
> > > contentHandler.startElement("", "item", "item", xspAttr);
> > > }
> > >
> > > It gives us the feature of redirecting SAX events
> > > to other XMLConsumers. (This would be a real seamless
> > > integration for the XForm and DOMObject implementation)
> > >
> > > There should be no undesired side effects...
> >
> > Yes, there are side effects with logicsheets that use
> > this.contentHandler.
>
> Then we make them not to use it, too ;)
>
> > I use the following construct to change the contentHandler :
> > <xsp:logic>
> > ContentHandler oldHandler = this.contentHandler;
> > try {
> > this.contentHandler = otherHandler;
> > ...
> > } finally {
> > this.contentHandler = oldHandler;
> > }
> > </xsp:logic>
>
> ...I was just not sure if changing the contentHandler in
> a multi thread environment is a good idea...
>
> ..but if this is really ok - I'm also fine with that!
> (Although a simple search and replace over logicsheets
> should be a bit cleaner - don't you think?)
>
Unfortunately, search/replace won't be enough : some complex logicsheets
(e.g. esql.xsl) split the generated code in sub-methods or inner
classes. This would require more changes in these.
> regards
> --
> Torsten
>
Sylvain.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: xsp.xsl
Posted by giacomo <gi...@apache.org>.
On Sun, 22 Jul 2001, Torsten Curdt wrote:
> > Torsten Curdt a écrit :
> > >
> > > Are there reasons or objections not to change
> > > the access to the contenthandler in the xsp.xsl
> > > from "this.contentHandler" to only "contentHandler"?
> > >
> > > Then we could do a local redirect of SAX events:
> > >
> > > ...
> > > contentHandler.startElement("", "item", "item", xspAttr);
> > > {
> > > AttributesImpl xspAttr = new AttributesImpl();
> > > XMLConsumer contentHandler = ...;
> > >
> > > contentHandler.startElement("", "item", "item", xspAttr);
> > > }
> > >
> > > It gives us the feature of redirecting SAX events
> > > to other XMLConsumers. (This would be a real seamless
> > > integration for the XForm and DOMObject implementation)
> > >
> > > There should be no undesired side effects...
> >
> > Yes, there are side effects with logicsheets that use
> > this.contentHandler.
>
> Then we make them not to use it, too ;)
>
> > I use the following construct to change the contentHandler :
> > <xsp:logic>
> > ContentHandler oldHandler = this.contentHandler;
> > try {
> > this.contentHandler = otherHandler;
> > ...
> > } finally {
> > this.contentHandler = oldHandler;
> > }
> > </xsp:logic>
>
> ...I was just not sure if changing the contentHandler in
> a multi thread environment is a good idea...
Don't worry. Generators are pooled so that one instance is dedicated to
one thread at a single point in time.
Giacomo
>
> ..but if this is really ok - I'm also fine with that!
> (Although a simple search and replace over logicsheets
> should be a bit cleaner - don't you think?)
>
> regards
> --
> Torsten
>
>
> ---------------------------------------------------------------------
> 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
RE: xsp.xsl
Posted by Torsten Curdt <tc...@dff.st>.
> Torsten Curdt a écrit :
> >
> > Are there reasons or objections not to change
> > the access to the contenthandler in the xsp.xsl
> > from "this.contentHandler" to only "contentHandler"?
> >
> > Then we could do a local redirect of SAX events:
> >
> > ...
> > contentHandler.startElement("", "item", "item", xspAttr);
> > {
> > AttributesImpl xspAttr = new AttributesImpl();
> > XMLConsumer contentHandler = ...;
> >
> > contentHandler.startElement("", "item", "item", xspAttr);
> > }
> >
> > It gives us the feature of redirecting SAX events
> > to other XMLConsumers. (This would be a real seamless
> > integration for the XForm and DOMObject implementation)
> >
> > There should be no undesired side effects...
>
> Yes, there are side effects with logicsheets that use
> this.contentHandler.
Then we make them not to use it, too ;)
> I use the following construct to change the contentHandler :
> <xsp:logic>
> ContentHandler oldHandler = this.contentHandler;
> try {
> this.contentHandler = otherHandler;
> ...
> } finally {
> this.contentHandler = oldHandler;
> }
> </xsp:logic>
...I was just not sure if changing the contentHandler in
a multi thread environment is a good idea...
..but if this is really ok - I'm also fine with that!
(Although a simple search and replace over logicsheets
should be a bit cleaner - don't you think?)
regards
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: xsp.xsl
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Torsten Curdt a écrit :
>
> Are there reasons or objections not to change
> the access to the contenthandler in the xsp.xsl
> from "this.contentHandler" to only "contentHandler"?
>
> Then we could do a local redirect of SAX events:
>
> ...
> contentHandler.startElement("", "item", "item", xspAttr);
> {
> AttributesImpl xspAttr = new AttributesImpl();
> XMLConsumer contentHandler = ...;
>
> contentHandler.startElement("", "item", "item", xspAttr);
> }
>
> It gives us the feature of redirecting SAX events
> to other XMLConsumers. (This would be a real seamless
> integration for the XForm and DOMObject implementation)
>
> There should be no undesired side effects...
Yes, there are side effects with logicsheets that use
this.contentHandler.
I use the following construct to change the contentHandler :
<xsp:logic>
ContentHandler oldHandler = this.contentHandler;
try {
this.contentHandler = otherHandler;
...
} finally {
this.contentHandler = oldHandler;
}
</xsp:logic>
> --
> Torsten
>
Sylvain.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org