I'm not sure I entirely understand what you are trying to do, here, but if
all you need to do is provide some XSP-derived data to an XSL document that
transforms chunks of XML into XHTML, then you were probably on the right
track by setting up a pipeline -- we do this using an aggregation and a
sub-sitemap.
Here is some example code that does something similar to what you've tried;
with this setup, things _do_ recompile on request -- eventually. We have in
fact noticed that at times it takes several seconds and/or several requests
for Cocoon to notice that a given XML or XSL doc has changed. On rare
occasions, a document seems to get "stuck" in Tomcat's work dir/cache, and we
have to toss it out manually.
Anyway...
Sample:
<map:pipelines>
<map:pipeline internal-only="true">
<map:match pattern="code/*.xsp">
<map:generate type="serverpages" src="CODE/{1}.xsp"/>
<map:serialize type="xml"/>
</map:match>
<map:match pattern="content/**.xml">
<map:generate src="{1}.xml"/>
<map:serialize type="xml"/>
</map:match>
</map:pipeline>
<map:pipeline>
<map:match pattern="**.html">
<map:aggregate element="page">
<map:part src="cocoon:/code/myxspstuff.xsp"/>
<map:part src="cocoon:/content/{1}.xml"/>
</map:aggregate>
<map:transform src="STYLESHEETS/generic-template.xsl"/>
<map:serialize type="html"/>
</map:match>
</map:pipeline>
</map:pipelines>
You can expand on this idea to gain very granular control over which XSP is
applied to which URL patterns. In your case I guess those would be your
frame targets.
CODE and STYLESHEETS are real directories containing the XSP and XSL,
respectively. "code" and "content" are fake and only used to address the
internal pipeline and are named distinctly to prevent confusion.
In this example we're taking requests for .html files, but actually fetching
.xml files and transforming them.
To use this setup, reference logicsheets in your XSP to access URL params,
cookies, etc...
myxspstuff.xsp:
<?xml version="1.0" encoding="UTF-8" ?>
<xsp:page language="java"
xmlns:xsp="http://apache.org/xsp";
xmlns:xsp-cookie="http://apache.org/xsp/cookie/2.0";
xmlns:xsp-request="http://apache.org/xsp/request/2.0";>
<xsp:structure>
<xsp:include>org.apache.cocoon.environment.Cookie</xsp:include>
</xsp:structure>
<stuff>
<CookieData>
<xsp-cookie:getCookie as="xml" name="COOKIE_NAME"/>
</CookieData>
<aVariable>
<xsp-request:get-parameter name="varname" default="nothing" as="xml"/>
</aVariable>
</stuff>
</xsp:page>
You can reference that directly with XPATH or you can convert them into XSL
variables within your XSL stylesheet:
<xsl:template match="*">
<xsl:variable name="showAds">
<xsl:choose>
<xsl:when test="contains(//premiumCookieData,
'ADS=N')">N</xsl:when>
<xsl:otherwise>Y</xsl:otherwise>
</xsl:choose>
</xsl:variable>
<xsl:variable name="subCategory">
<xsl:value-of select="//@subCategory"/>
</xsl:variable>
<xsl:variable name="pn">
<xsl:value-of select="//pageRequested"/>
</xsl:variable>
</xsl:template>
If in fact you need to invoke logic within the body of a document to get some
output, rather than prior to its transformation, then using a custom
logicsheet is probably your best bet. And it will keep your actual logic out
of the content. There's an updated tutorial on adding a logicsheet to
Cocoon in the dev tree now, I think -- the old docs on the site are/were
geared towards c1.
On Wednesday 06 March 2002 01:08 pm, you wrote:
> Well, that's it. I'm almost ready to scrap Cocoon.
>
> All I want to do is generate a simple HTML page that when requested
> does a little Java code first using some request parameters and
> values from the XML it's being generated from. I need to do this in
> many little ways: sending email, writing to a log, accessing
> services and sending data.
>
> Like:
>
> source.xml:
> <foo id="100">
> <bar>Hello</bar>
> <foo>
>
> write.xsl?write=test (submitted via form):
> <xsl:param name="test"/>
> <xsl:template match="foo">
> <html>
> <xsp:logic>
> SpecialLogger logger = new SpecialLogger(<xsl:value-of
> select="@id"/>);
> if (logger.writeThis("<xsl:value-of select="$test"/>")) {
> <body>
> <xsl:value-of select="bar"/> worked!
> <!-- body content version A -->
> </body>
> } else {
> <body>
> <xsl:value-of select="bar"/> didn't work
> <!-- body content version B -->
> </body>
> }
> <xsp:logic>
> </html>
> </xsl:template>
>
> + ~20 other xsl files that spit out frames based on the same XML
> but only require barebones XSLT
>
> This is important because this runs in a framed environment where
> all frames' HTML use the same XML as source, and I don't want to
> have any special code in the XML because there will be many of
> these sources soon, and it only needs to execute this code for this
> *one* transformation.
>
> The only way I have gotten this to work is to create a pipeline
> that turns the XML into an XSP and have the real URL match to a
> cocoon:/ protocol to generate that XML-to-XSP pipeline. While this
> works, it creates a class that WILL NOT RECOMPILE no matter how
> much the referenced XML changes until I restart Cocoon or manually
> delete it, which is unacceptable.
>
> It is absolutely imperative that I be able to accomplish this
> without adding any Java classes--I just won't have the access
> needed to do this.
>
> There MUST be a way!
>
>
> ---------------------------------------------------------------------
> 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: <[EMAIL PROTECTED]>
> For additional commands, e-mail: <[EMAIL PROTECTED]>
---------------------------------------------------------------------
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: <[EMAIL PROTECTED]>
For additional commands, e-mail: <[EMAIL PROTECTED]>
