Ways to implement Dynamic XSLT in Cocoon

[Matt Robinson <ma...@flightcentre.com>]

Hello.

Has anyone come across or written an transformer-based way to dynamically modify an XSLT template at processing time?

My challenge is this:

To facilitate Web Metric analysis, we need to embed vendor-supplied JAVA script in each page.  This JAVA script (and/or vendor) may change over time, and I want to maintain separation of concerns such that the business (as opposed to the Cocoon
Development Team) can make changes to the vendor and/or JAVA script content without requiring changes to the site coding.

The JAVA script is very dynamic and may include page-specific code that makes use of data embedded in the page, as well as common variables.  In short, we cannot include the script in the XSLT directly because of it's dynamic nature and the lack of XSLT
knowledge in the business.

I would like to implement a strategy whereby the script for the entire site is encapsulated in an XML file for each Web Metrics vendor, and a transformer uses this XML, coupled with a Page ID to add a template to the XSLT stylesheet instance being
transformed by the Xalan SAX Parser at build time.  The page data to insert will be represented as XPaths embedded within the extra XSLT template.

My investigations show that a good approach would be to make a copy of the TraxTransformer and intercept the XSLT data before it is actually transformed, adding the template (which has been added to the pipeline SAX events by my new
WebMetricsTransformer), and then passing a StringReader containing the new XSLT Source object into the transform.

Any constructive comments would be greatly appreciated

Kind Regards,

Matt Robinson



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

Re: Ways to implement Dynamic XSLT in Cocoon

[Mark Lundquist <ml...@wrinkledog.com>]

On Jan 19, 2005, at 7:48 PM, Matt Robinson wrote:

> Hello.
>
> Has anyone come across or written an transformer-based way to 
> dynamically modify an XSLT template at processing time?

The "normal" way to do that would be to process your "first order" 
stylesheet through a "second-order" stylesheet, and use the "cocoon:" 
pseudoprotocol to invoke the pipeline that does this, e.g.

	<generate src="some-XML"/>
	<transform src="cocoon:/get-stylesheet" />

But I'm not sure it even has to be that involved...

> My challenge is this:
>
> To facilitate Web Metric analysis, we need to embed vendor-supplied 
> JAVA script in each page.  This JAVA script (and/or vendor) may change 
> over time, and I want to maintain separation of concerns such that the 
> business (as opposed to the Cocoon
> Development Team) can make changes to the vendor and/or JAVA script 
> content without requiring changes to the site coding.
>
> The JAVA script is very dynamic and may include page-specific code 
> that makes use of data embedded in the page, as well as common 
> variables.  In short, we cannot include the script in the XSLT 
> directly because of it's dynamic nature and the lack of XSLT
> knowledge in the business.
>
> I would like to implement a strategy whereby the script for the entire 
> site is encapsulated in an XML file for each Web Metrics vendor, and a 
> transformer uses this XML, coupled with a Page ID to add a template to 
> the XSLT stylesheet instance being
> transformed by the Xalan SAX Parser at build time.  The page data to 
> insert will be represented as XPaths embedded within the extra XSLT 
> template.
>
> My investigations show that a good approach would be to make a copy of 
> the TraxTransformer and intercept the XSLT data before it is actually 
> transformed, adding the template (which has been added to the pipeline 
> SAX events by my new
> WebMetricsTransformer), and then passing a StringReader containing the 
> new XSLT Source object into the transform.
>

Why not

	<script language="javascript" src="Metrics.js" />

???

I can't imagine why the JS would have to be inline, but if it did, you 
could

(a) interpolate it using the Xinclude or Cinclude transformer; or,
(b) interpolate it using the Xpath document() function (note, the URI 
can use the "cocoon:" scheme); or,
(c) use map:aggregate to get it into the same source stream, and merge 
it in in your stylesheet

All of those are standard Cocoon techniques that don't require any 
custom componentry.  It seems like you're wrapped around the axle of 
"must get JS into the stylesheet", and while there's an easy way to do 
that (see the very beginning of this post), but if all you need to do 
is get some content into your final output, there are plenty of simpler 
ways to do that.  Or maybe I'm just not understanding your problem 
correctly?

cheers,
—ml—

RE: Ways to implement Dynamic XSLT in Cocoon

[Conal Tuohy <co...@paradise.net.nz>]

Matt Robinson wrote:

> Has anyone come across or written an transformer-based way to
> dynamically modify an XSLT template at processing time?

Yes. See http://wiki.apache.org/cocoon/MetaStylesheets and also
http://wiki.apache.org/cocoon/HtmlToXsltExperiments

Cheers

Con


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

Re: Ways to implement Dynamic XSLT in Cocoon

[Andrzej Jan Taramina <an...@chaeron.com>]

Matt:

> Has anyone come across or written an transformer-based way to dynamically
> modify an XSLT template at processing time?
> 
> My challenge is this:
> 
> To facilitate Web Metric analysis, we need to embed vendor-supplied JAVA
> script in each page.  This JAVA script (and/or vendor) may change over time,
> and I want to maintain separation of concerns such that the business (as
> opposed to the Cocoon Development Team) can make changes to the vendor and/or
> JAVA script content without requiring changes to the site coding.
> 
> The JAVA script is very dynamic and may include page-specific code that makes
> use of data embedded in the page, as well as common variables.  In short, we
> cannot include the script in the XSLT directly because of it's dynamic nature
> and the lack of XSLT knowledge in the business.

I've done this in an application I designed and wrote.  The HTML page 
returned to a user is generated by a transform, since it's based on an XML 
input document.  The javascript that is used by this page is also generated 
dynamically based on that same XML input.

> I would like to implement a strategy whereby the script for the entire site is
> encapsulated in an XML file for each Web Metrics vendor, and a transformer
> uses this XML, coupled with a Page ID to add a template to the XSLT stylesheet
> instance being transformed by the Xalan SAX Parser at build time.  The page
> data to insert will be represented as XPaths embedded within the extra XSLT
> template.
> 
> My investigations show that a good approach would be to make a copy of the
> TraxTransformer and intercept the XSLT data before it is actually transformed,
> adding the template (which has been added to the pipeline SAX events by my new
> WebMetricsTransformer), and then passing a StringReader containing the new
> XSLT Source object into the transform.

This sounds overly complex to me.

Why not take the approach I used, which was to create a separate pipeline 
that outputs the customized javascript, looking something like the following:

<map:pipeline>
	<map:match pattern="customJavascript.js">
		<map:generate src="{request-param:pageID}-{request-param:vendor}-
jsdefinition.xml"/>
		<map:transform src="createJavascript.xsl">
			<map:parameter name="pageID value="{request-param:pageID}"/>
			<map:parameter name="vendor" value="{request-param:vendor}"/>
		</map:transform>
		<map:serialize type="text"/>
	</map:match>
<map:pipeline>

In this example, there are two request parameters passed in, pageID and 
vendor. The encapsulated script is found in files that look like pageid-
vendor-jsdefinition.xml and you have a simple xsl called createJavascript.xsl 
which extracts the javascript from the xml def, potentially modifies it using 
the passed in parms and returns pure .js.

Then in the xsl transform that is creating the actual HTML page for the user 
you just do something like this, at the point where you want to embed the 
custom javascript:

	<xsl:variable name="scriptURL" 
		select="concat( 'cocoon:/customJavascript.js?pageID=', $pageID, '&vendor', 
$vendor )"/>

	<xsl:copy-of select="document( $scriptURL )"/>

That seems a lot simpler than your approach.


Andrzej Jan Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com


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