Reinhard Pötz wrote:
If I understand this correctly I get with
source.getValidity()
the SourceValidity.
Yes.
But if I call e.g. cocoon://blablalba.xml this
method returns null. The default pipe is the caching pipe
and I use it with
map:pipeline
...
/map:pipeline
If I resolve a
From: Carsten Ziegeler [mailto:[EMAIL PROTECTED]
Reinhard Pötz wrote:
If I understand this correctly I get with
source.getValidity()
the SourceValidity.
Yes.
But if I call e.g. cocoon://blablalba.xml this
method returns null. The default pipe is the caching pipe and I
From: Christopher Oliver [mailto:[EMAIL PROTECTED]
You're right. But it's a bad idea to use the cocoon://
protocol as the
source for JXTemplateGenerator (as it would be also for
TraxTransformer,
for example). In effect you are generating a new program for every
request, that must
on 6/22/03 3:32 PM Christopher Oliver wrote:
In Linotype I saw some other strange uses of the cocoon:// protocol that
appear to be very bad for performance:
There's a pipeline that uses the directory generator to read a
directory, and transforms it using xslt into a cinclude template.
If I call the method getLastModified() for cocoon://
sources the return value is always 0. Is this the
correct behaviour?
If yes at least the JXTemplateGenerator (line 2868)
doesn't work correctly and I think some more components too.
Reinhard
From: Sylvain Wallez [mailto:[EMAIL PROTECTED]
Reinhard Pötz wrote:
If I call the method getLastModified() for cocoon://
sources the return value is always 0. Is this the
correct behaviour?
Yes !
If yes at least the JXTemplateGenerator (line 2868)
doesn't work correctly and
