cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wendell Piez <wap...@mulberrytech.com>
Subject Re: document() function in Saxon 8.3 under Cocoon 2.1.7
Date Sat, 09 Apr 2005 17:27:07 GMT
Thanks JP for this illuminating information (even if I feel a bit like I'm 
looking at the trees from the bottom of a swimming pool :-).

I will poke further and see what I can learn. In particular, the insight 
that the problem is probably related to caching is useful.

A little more background as to what I'm trying to do. I want to use 
document() to discern the dimensions of graphics. For rasters, I can get 
this information out of an image directory, and I can see how I could wrap 
this via pipeline aggregation and get access to the info this way. (I've 
used document() successfully in other contexts for this, but can see how 
aggregation is tighter here.)

For SVGs, however, the image directory gives me nothing, so I'd actually 
like to query the SVG itself to determine the dimensions provided on its 
/svg/@width and /svg/@height.

If a designer changes an SVG, I'd like the content that calls that SVG in 
to update gracefully, which means querying it again. So yeah definitely, a 
potential caching issue (now my head is starting to hurt). Maybe I will 
have to introduce some restriction or requirement that an SVG can't be 
altered without also touching the file(s) that call it in.

If an image directory were to include width and height of SVGs as well as 
rasters, I'd be in business ... I guess here the caching issues have 
already been addressed. This suggests a solution would be a preprocess that 
would generate a directory of available SVGs, which I could aggregate. (But 
how to trigger it, and how to implement?)

(Would it help to turn off caching, at least as an experiment?)

Anyhow, I can see this is deeper than I'd thought, so I am very grateful 
for the help. Maybe there's already an elegant solution to the 
reading-dimensions-of-SVGs problem, using Cocoon constructs of which I'm 
still unaware to get me around document().

Cheers,
Wendell

At 03:18 AM 4/9/2005, you wrote:
>Wendell Piez wrote:
>>Yes. Further research has suggested that problems with it in the past 
>>should have nothing to do with this case. The FAQ warns against 
>>document() and offers intelligible reasons for avoiding it, but 
>>apparently it is supposed to work.
>
>Well, in the 2.0.x series and early 2.1.x releases changes in content
>pulled in via document() indeed didn't cause invalidation of the
>cached pipeline result. Touch one of the sources of the generators
>in the pipeline, or the stylesheet itself in order to reset the
>cache and see whether it helps.
>
>In my experience, Saxon 7.3 also had the habit of logging NPEs
>from its EntityResolver and occasionally causing failures when
>using document() in Cocoon 2.1.5. I was not able to reproduce
>the problem consistently, and ultimately switched to pipeline
>aggregation and XInclude.
>
>J.Pietschmann

___&&__&_&___&_&__&&&__&_&__&__&&____&&_&___&__&_&&_____&__&__&&_____&_&&_
     "Thus I make my own use of the telegraph, without consulting
      the directors, like the sparrows, which I perceive use it
      extensively for a perch." -- Thoreau 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Mime
View raw message