cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tagunov Anthony" <atagu...@nnt.ru>
Subject Re: util:include + xsp problem
Date Thu, 15 Mar 2001 16:45:40 GMT
On Thu, 15 Mar 2001 11:07:57 -0500, paint007@mc.duke.edu wrote:

>
>Why exactly is using the XInclude processor before the XSP processor a
>hack?  I'm doing this now so that I can get reusability out of my code
>(some XML fragments can be shared among different pages).  The caching

YES!!! YES!! YESS!! That's i wanna do too!!!

>issue is annoying, but I just touch the including files every time I change
>an included file, which is adequate in a development environment.  This
>won't be an issue for me in production as I'll touch everything when I
>release new code.

Well, i beleive it is a feasable solution.
That's what i do too.
The only trouble is some implementation overhead:
evry time the request is considered invalid
(isValid has returned true) 
the processors that come before XSPProcessor are
run. They read the files from disk, 
XInclude merges them, then XSPProcessor checks the
date of the source file (main one), consideres the compiled
code valid and discards the code generated prior to it.
Then the compiled code runs. This is the overhead:
every time the request is served not from Cocoon cache,
the processors prior to xsp run too (but with no use)

>The bits of code that I'm including are completely independent, producing
>their own XML nodes for processing in the xsl files (which are also
>factored to match the xml and included using xsl:import).  Is there a
>better way to do this?
>
>I assume that opening an XML file with XSP code from an XSLT using document
>() won't work because the XSP processor won't run on the file first.
>Correct?

No. document() will work okay. And if this is logicsheet/taglib xsl you even
won't have the overhead described above. (But changes detection you
won't get either)

>Has anyone looked at the XInclude processor to see how hard it would be to
>deal with the caching issue?  (While I'm at it, another item on my wish
>list would be for XInclude to detect when an included XSP file has
>compilation errors, and show me *those* errors instead of the generic
>XInclude exception I always get.  That would make debugging easier!)

Yes. I have. Both on XInclude and XSPProcessor. This is XSPProcessor
issue. The XInclude processor work okay and does signal isValid()==false
when appropriate. The trouble is XSPProcessor has no way to use this info.

It's broke. It's desperate. Nothing can be done without a _FULL_ refactoring
of the caching and processing mechanisms in C1.

It would be best to through every effort on Factoring a _good_ caching system
for C2 (there's none there yet) It is there that we should try to implement our
dream of nice and easy combination of XInclude and XSL functionality that
gets engaged prior to XSP.

The good news is that there's an understanding that XSP should undergo some
changes and becomd XSP 1.1 or even 2.0 (counting current as 1.0)

The bad news is that evrth is muddy there and not evoluting much (as i can see
from the cocoon-dev)

As for C2 it's a question: should we ask the developers to have other processors
before XSP processor (currently it is disallowed). Dunno!

I'm currently flaming XSP-dev on including XInclude functionality in the core of
XSP specifiactions (i beleive that it belongs there either as
<xsp:include> or as <xsp-preporcessor:include> there) so that it would run
without having to run any processors before xsp processor.

>-Christopher
>
>
>
><snip>
>
>XInclude is not the case because nothing should run
>before xsp processor in C1 (actually you can
>place <?cocoon-process type="xinclude"?>
>before <?cocoon-process type="xsp"?>
>but this should be considered a hack and will
>have the drawback that whenever you change the
>file being included the cache will be cleaned for the
>page, but the page really won't be recompiled.
>
><snip>
>
>
>
>---------------------------------------------------------------------
>Please check that your question has not already been answered in the
>FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
>
>To unsubscribe, e-mail: <cocoon-users-unsubscribe@xml.apache.org>
>For additional commands, e-mail: <cocoon-users-help@xml.apache.org>
>
>
>
>
>
>
>
>
>---------------------------------------------------------------------
>Please check that your question has not already been answered in the
>FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
>
>To unsubscribe, e-mail: <cocoon-users-unsubscribe@xml.apache.org>
>For additional commands, e-mail: <cocoon-users-help@xml.apache.org>
>
>




---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>

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


Mime
View raw message