Cyriaque Dupoirieux a écrit :
Ross, I have to go now, I'll be back on thursday...
Thank you for your help,
Cyriaque,
Ross Gardler a écrit :
Cyriaque Dupoirieux wrote:
Ferdinand Soethe a écrit :
This is untested, but would be where I would start experimenting
and I'm
pretty sure is close to correct (maybe even correct ;-).
Thanks Ross, that was exactly what I was looking for. I just didn't
know where to intercept. Will give it a try right away ...
Hi,
I made this in my php pipeline :
<map:pipeline>
<!-- PHP Documentation -->
<map:match type="regexp" pattern="^(.*?)([^/]*).php$">
<map:generate src="cocoon://{1}{2}.html"/>
<map:transform src="resources/stylesheets/php/document2php.xsl"/>
<map:serialize type="html"/>
</map:match>
What does document2php.xsl do? Is this appraoch better for Ferdinand
than the one I suggest?
It just transform the <php> and </php> tags into *<?php* and *?>*...
In fact, I have created an output plugin for php format.
This plugin match php extension file in order to generate the skinned
HTML and clean the <php> and </php> tags between which I put php calls.
On the paper it was simple, my problem is the horible performance I get
to generate the skinned HTML.
With the Cocoon Profile I get :
1 file /src=/cocoon://livres/livres.html 3031 3031 3031
2 xslt /src=/resources/stylesheets/php/document2php.xsl 46
46 46
to get a php file whereas it takes arround 100 to get a "normal" skinned
HTML page...
</map:pipeline>
And I realise with the cocoon profiler - thank you Ross - that it takes
(don't thank me for the profiler that was Ron and Davids excellent
work - and the Cocoon community of course)
lot of time to call the <map:generate src="cocoon://{1}{2}.html"/> -
and certainly lots of CPU because with dozens of php files I get an
Out of Memory... -
It should take no longer to request cocoon//**.html that it does to
request it via your browser. So the issue is not really with you
approach to including PHP stuff, rather with the generaton of the
original HTML stuff.
Are you using the locationmap to retrieve remote files in this request?
No, all is local...
Ross
