On Fri, 5 Jul 2002, Piroumian Konstantin wrote:
> > From: Jason Foster [mailto:[EMAIL PROTECTED]] > > > > The process that I am envisioning looks something like this... <snip/> > > Another problem is that the DocBook stylesheets assume that > > there will be > > a "driver" stylesheet that looks like: <snip/> > You can do it this way: > - First pipeline generates the content transformations into PDF and > calls the second pipeline to obtain the needed stylesheet > - Second pipeline generates a stylesheet depending on request params > and using a stylesheet template Why not pass the request params to the driver stylesheet and thence up the tree. ./docbook.xsl can be, and call other, static resource with these dynamic values. The xsl:include production is a textual inclusion at the point of reference, absent the include's xsl:stylesheet element. An assignment to an xsl:variable is available to all subsequent templates in a pass through a transform. If prior to the inclusion they will be available to the included stylesheet's templates throughout. Your defaults can live in ./session-defaults.xsl which you might like to generate in order to access session state, but for now can be static assignments of default values. The beef of your driver looks like this: <xsl:import href="./session-defaults.xsl">" <xsl:variable name="my_docbook_flag" select="$how_cocoon_calls_param1_from_request"/> <xsl:include href="./docbook.xsl"/> All the templates of ./docbook.xsl (and the templates of its inclusions) now have access to the default flags plus the latest value for $my_docbook_flag, relying on import precedence. That's probably the main reason to have a driver. ---------------------------------------------------------------- Mike Haarman [EMAIL PROTECTED] Maintainer, DDI Codebook DTD -- http://www.icpsr.umich.edu/DDI/ --------------------------------------------------------------------- Please check that your question has not already been answered in the FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html> To unsubscribe, e-mail: <[EMAIL PROTECTED]> For additional commands, e-mail: <[EMAIL PROTECTED]>
