cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vadim Gritsenko" <vadim.gritse...@verizon.net>
Subject RE: [PATCH] AW: XSP page getting called TWICE! (using pipeline as a transformer)
Date Thu, 13 Dec 2001 20:47:04 GMT
Wolfram,

I applied your patch (with some modifications); please check that
everything is working for you.

> Because XSP-Pages currently aren't cacheable (as far as I know)
> no template is saved, so this happens each time the
> page is called.

Regarding XSP page caching, you need to define couple of methods. Read
on about caching of XSP in the thread:
http://marc.theaimsgroup.com/?l=xml-cocoon-users&m=100142724706511&w=2

(This theme were discussed at least couple of times on user list)

Vadim

> -----Original Message-----
> From: Eisert, Wolfram [mailto:Wolfram.Eisert@Dresdner-Bank.com]
> Sent: Wednesday, December 12, 2001 10:37 AM
> To: 'cocoon-dev@xml.apache.org'
> Subject: [PATCH] AW: XSP page getting called TWICE! (using pipeline as
a
> transformer)
> 
> Hi David,
> 
> the origin of this problem has something todo with using
> a cocoon-pipeline as a transformer-stylesheet which leads
> to processing this pipeline more than one time.
> A similiar problem occured in our app some time ago.
> 
> I think it's a problem in XSLTProcessorImpl.
> 
> Attached is a PATCH against cocoon_20_branch to fix the problem.
> 
> I will give a short description of the behaviour so that
> someone can have a look on it.
> 
> During setting the consumer the XSLTProcessorImpl
> is calling "stylesheet.getInputSource()" more than one time
> (while searching for an existing template in memory).
> For a SitemapSource each call leads to a processing of the hole
> pipeline which also fires the generator every time this method is
> called.
> 
> Because XSP-Pages currently aren't cacheable (as far as I know)
> no template is saved, so this happens each time the
> page is called.
> 
> The attached patch calls "getInputSource" only once and uses
> the returned InputSource in any subcalls.
> 
> Another "cleaner" solution would be just to use
stylesheet.getSystemId()
> instead of inputSource.getSytemId() - but I don't know if the
> result is allways the same ;-).
> 
> Could someone please check my changes and apply the patch?
> 
> Thanks,
> 
> Wolfram
> 
> > -----Urspr√ľngliche Nachricht-----
> > Von: David Rosenstrauch [mailto:darose@dti.net]
> > Gesendet am: Montag, 10. Dezember 2001 20:12
> > An: cocoon-dev@xml.apache.org
> > Betreff: Fwd: XSP page getting called TWICE!
> >
> > Can someone help?
> >
> > I've got a rather complex problem with C2 which I've not been
> > able to figure out despite some major debugging sessions.
> > Posted this several times to the Cocoon Users list too, but
> > no one had any info.
> >
> > I'm suspecting the problem I'm seeing might be a bug in C@,
> > but maybe someone here might be able to tell me for sure.
> >
> > Details about my problem are in the message below.
> >
> > I'm using C2, RC1a, if that matters.
> >
> > TIA!
> >
> > DR
> >
> >
> > >Date: Fri, 07 Dec 2001 12:07:52 -0500
> > >To: cocoon-users@xml.apache.org
> > >From: David Rosenstrauch <darose@dti.net>
> > >Subject: XSP page getting called TWICE!
> > >
> > >Actually, regarding the setup below, I'm having a problem
> > with it and would appreciate some help.
> > >
> > >Take a look at the sitemap segment below.  And let me
> > clarify it a bit too:
> > >
> > >The XSL stylesheet that I'm using in the transform on
> > "pd/mergedoc.html" is generated *dynamically*, from an xsp
> > page ("pages/gen_merge_xsl.xsp").
> > >
> > >This is working just fine, except for one small problem:
> > >
> > >For some reason, on each request, this XSP page is getting
> > executed TWICE!  Although this doesn't technically cause any
> > errors, it's pretty inefficient since it hits the database
> > twice, generates the xsl twice, etc.
> > >
> > >Any ideas why?
> > >
> > >Some possible thoughts I had:
> > >
> > >* perhaps the internal-only="true" is causing this?
> > >
> > >* perhaps an additional aspect of this setup is causing
> > this:  the "cocoon:/rtf_parse" generation step (not listed)
> > is setting an "attachment" response header
> > ("Content-Disposition: attachment; filename=myfile.rtf") so
> > that the file will be downloaded instead of displayed
> > directly in the browser.  Could that be causing this?
> > >
> > >Any help appreciated!
> > >
> > >TIA!
> > >
> > >
> > >DR
> > >
> > >
> > > ><map:pipeline>
> > > >          <map:match pattern="pd/mergedoc.html">
> > > >                  <map:generate src="cocoon:/rtf_parse"/>
> > > >                  <map:transform src="cocoon:/rtf_merge_data"/>
> > > >                  <map:serialize type="rtf"/>
> > > >          </map:match>
> > > ></map:pipeline>
> > > >
> > > >
> > > ><map:pipeline internal-only="true">
> > > >          <map:match pattern="rtf_merge_data">
> > > >                  <map:generate type="serverpages"
> > src="pages/gen_merge_xsl.xsp"/>
> > > >                  <map:serialize type="xml"/>
> > > >          </map:match>
> > > ></map:pipeline>
> >
> >
> >
---------------------------------------------------------------------
> > 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


Mime
View raw message