I've just been looking at "inclusion" recently and noticed that the cinclude
transformer had caching but the xinclude transformer didn't, and I wondered
if there was some arcane reason or was it just a historial accident ;-) And
BTW I think Carsten is right - the inclusion code should be united.
But actually my question is about caching of the DirectoryGenerator and
sub-classes. It seems to me that these transfomers should also be cacheable;
maybe this is just an oversight too? Or is there something tricky I haven't
forseen? ;-)
I have a pipeline based on a directory listing of xml docs; with 9 documents
it takes 2 or 3 seconds to complete - and with 100 docs it will be
impossible. But the files aren't often changed.
Anyway, I thought I might make an attempt at adding caching to the
DirectoryGenerator. It seems to me that the generator could perform the
search and traverse the file system every time a request is made, but hash
the resulting xml for the CacheValidity. Is that right? This would be my
first attempt.
I could enhance it to only traverse PART of the file system again to check
the validity, by keeping a record of the file and directory objects involved
in the last search. In the case of a directory search like "images/*.jpg",
or "docs/*.xml", the generator should only need to check the timestamp of
the "images" or "docs" directories, is that right? I've also used searches
like "images/{1}.jpg" with the ImageDirectoryGenerator, to get the image
width and height into a pipeline that converts the jpg to svg, for scaling,
etc. In this case the validity could depend on the timestamp of that single
file.
Any hints or comments would be much appreciated!
Con
> -----Original Message-----
> From: Carsten Ziegeler [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, 12 June 2002 19:03
> To: [EMAIL PROTECTED]
> Subject: RE: XInclude Transformer vs CInlude Transformer
>
>
>
> >
> > Carsten? Donald? Why we have two transformers?
> > :)
> >
> I don't remember the exact reason, but I think Stefano brought this up
> originally.
> The xinclude transformer implements the xinclude spec, but
> the cinclude
> transformer was invented to bring an easier and more
> intuitive notation for
> including documents. I quickly searched through the mail
> archive but didn't
> find the original mails...
>
> To be more precisly, we have three transformers doing the
> job! The session
> transformer also has an include concept which is more
> detailed than xinclude
> and cinclude as it can also do POST operations, pass parameters etc.
>
> I personally don't see a real problem in having different
> notations for the
> same job, but perhaps we can make one code bass out of it,
> let's say an
> include transformer doing xinclude, cinclude and the include
> job of the
> session transformer.
>
> Carsten
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
