forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John Morrison" <>
Subject RE: Graph data
Date Wed, 20 Feb 2002 21:53:20 GMT
> From: Steven Noels []
> 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 was also looking at this approach, but couldn't find an example
which explained it sufficiently stupidly for me to follow :(

> Seriously:


> 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.

I'm in two minds - I can see both arguments and I'd normally come down
on the "don't manually duplicate data".  I think leave it as it is until
proven otherwise.

> 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.

change to CInclude...?

> We could skip the XInclude part doing an XSLT
> transformation using
> document() functions mounted directly on top of our
> DirectoryGenerator.

don't like.

> 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!),

patches, patches, patches :)

> I'd be happy to play around with it until it works
> (and you guys
> are sick of my patches :-)

Oh - don't worry - a few more days and I was going to *seriously*
consider nominating you ;)

> John, did you take a look at
> ?

I know of Jeni's work, but this is a new page on me.  Took a quick look,
don't *believe* there's anything there we need, but I've been wrong

(note to self: does she support -ve y?)

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

Thanks for the comments,


View raw message