forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steven Noels" <>
Subject RE: Graph data
Date Wed, 20 Feb 2002 21:36:32 GMT
John Morrison wrote:

> The only possible things which spring to mind would be to possibly:
> 1) don't group the data but repeat date information per datum
> 2) only have one source file and save doing the xinclude stuff...
> Steven, any other things you can think of?

Well, I arrived with a working and reasonably compact XSLT solution, which is
using a so-called XSLT Design Pattern widely advocated by the gurus (Muenchian
grouping). So I consider this being a nice exercise for XSLT engines doing what
they proclaim to be doing well (i.e. xsl:key).


I'm reasonably happy with the result, and the resource intensive part can be
considered a relevant test of the cache constructs in Cocoon: each daily raw
file undergoes a mini-identity-transformation, adding some attributes to each
child datum element. This should be an XSLT no-brainer in execution - but
there's a lot of them. We can get rid of this step if Sam's script adds the date
information per datum. Since these are all operations on static documents not
using any request parameters, all the processed daily logs should be in the
cache afterwards.

Next, there's the XInclude part doing some XPointer stuff: these are supposedly
pretty basic operations, but it means parsing a lot of documents. The XInclude
Transformer doesn't implement Cacheable, which is a problem for this case, I
presume. We could skip the XInclude part doing an XSLT transformation using
document() functions mounted directly on top of our DirectoryGenerator. I did
this once as a showcase of the document() function, but I'm pretty sure
document() plays nasty tricks with Cacheable, too.

I like the DirectoryGenerator approach because it gives us the possibility to
list a partial data set using some clever wildcards. Besides that, the
document() function locates files to be included relative to the stylesheet
location, which means I would need to hardcode the data files' location in the
stylesheet - bound to break when files are re-shuffled some day.

All-in-all, I would prefer to put the current approach to test and do some
benchmarking. If we can get a working basic Cocoon framework put into CVS
(Centipede!), I'd be happy to play around with it until it works (and you guys
are sick of my patches :-)

John, did you take a look at ?

Stefano, do we have a final on the HTML lay-out so that I can start cranking up
stylesheet (fragments) for our DTD's?



View raw message