Petals SE XSLT

Ok cela fonctionne avec les paramètres que j'avais mis, il suffisait d'utiliser le bon composant XSLT...

Note : In some case this trick is not valid, you cannot have "{...}" in the select attribute of a value-of element. You should use instead :

<xsl:value-of select="$toto" />

Hi,

Instead of writing

<xsl:value-of select="$toto"/>

try with

<xsl:value-of select="{$toto}"/>

I have made a test with a similar style sheet and the same variable and value.
You can take look at this page for more information.
I will update the documentation of the XSLT SE.

Bonjour,

Je n'arrive pas à utiliser cette fonctionnalité...

J'ai ajouté les lignes suivantes dans le jbi.xml de la Su-XSLT-Provide :

<xslt:stylesheet>AD004_InfosMissionLite_vers_IDT-MP0024_01.01.xsl</xslt:stylesheet>
<xslt:xsl-parameters>
<xslt:xsl-parameter name="toto" overridable="false">VEBP</xslt:xsl-parameter>
</xslt:xsl-parameters>

Et ma XSL :

<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:rqst0="http://schemas.datastream.net/MP_functions/MP0024_001" xmlns:imlt="http://veolia.ban.com/eau/SI/Mobilite/objet/InfosMissionLite/v01" xmlns:a="http://schemas.datastream.net/MP_fields" xmlns:b="http://veolia.ban.com/eau/Reseau/Intervention/service/AD004/v01" xmlns:org_ow2_petals_transco_Transcodifications="org.ow2.petals.transco.Transcodifications">
	<xsl:import href="substring_IDT_IdMission.xsl"/>
	<xsl:param name="toto"/>
	<xsl:template match="/">
		<rqst0:MP0024_GetWorkOrder_001>
			<a:WORKORDERID>
				<a:JOBNUM>
					<xsl:call-template name="substringIDTIdMission">
						<xsl:with-param name="IdMission" select="b:recupMissionSigma/infosMissionLite/imlt:idMission"/>
					</xsl:call-template>
				</a:JOBNUM>
				<a:ORGANIZATIONID>
					<a:ORGANIZATIONCODE>
						<xsl:value-of select="$toto"/>
					</a:ORGANIZATIONCODE>
				</a:ORGANIZATIONID>
			</a:WORKORDERID>
		</rqst0:MP0024_GetWorkOrder_001>
	</xsl:template>
</xsl:stylesheet>

Commit # 15591
Another implementation was committed, passing the XSL parameters to the transformer, instead of replacing variables in the input stream.
This opens the door to a new feature (passing dynamic parameters through an invocation message).

In fact, parameters should be declared in the XSL as real XSL parameters, and not as template variables, like I initially thought.
See here for an example: http://projects.ischool.washington.edu/tabrooks/545/ContentManagement/PassingParameters.htm
On SU start, the XSLT SE will update the content of these parameters with the content of the jbi.xml.

Commit # 15586
The XSL parameters are injected in the referenced XSL when the SU is started.
The variables are defined in the jbi.xml, as follows:

<xslt:stylesheet>transformation.xsl</xslt:stylesheet>
<xslt:xsl-parameters>
<xslt:xsl-parameter name="toto">namespace::*</xslt:xsl-parameter>
</xslt:xsl-parameters>

The variable can refer to any text.
With this example, the _$toto variable will be replaced by "namespace::*" (without the quotes).
If you have a better to idea to name the variable (another syntax), please make your proposals here.
Be careful, having such variables in your XSL makes it invalid by default.

> If the variables are defined in the jbi.xml, would it be OK for you?

I read the title and I see you did not expect another solution.
I will go with it. I may adapt the XML structure that I previously described. But the idea is the same.

I just attached a SU with 4 XSL. The only difference between them is just a constant.

Maintaining these 4 XSL is time consuming. Since we can have 2 SU using 2 different constant, we can't use component nor environment defined property. It would be better if we had a jbi property on the SU, since we can use a ${variable} and a property file to customize this constant.

Technically, it is feasible.

However, with your example, which is an environment related-thing, it would make more sense to configure it at the component level.
Or was it just an example? The feature would be to customize the XSL style sheet by defining any variable. That is to say not just environment ones?

Hi, I was more thinking about a parameter in the jbi.xml of the SU that would applied only on the XSL of this SU.
I don't know if this is possible or not?

Hi,

And this parameter would apply to all the SU deployed on this component?
If so, here is what we could do:
+ It is possible to pass a properties files to the component.
+ In this properties file, you could define ${XXX} and set its value (prod, dev...).
+ Before compiling the XSL style sheet, the component would replace the variables by the value defined in the component properties. The way this variable is written in the XSL would probably be something like ${_variableName_} (otherwise, it would be too similar to XSL variables).

I still wonder if we would need a new parameter in the SU to use the component properties or not.
Anyway, I think it could be done for the end of the week, provided we agree on what we want to do.

XSL code: <xsl:value-of select="concat('idtapptest/web/base/VIEWUDOC?filename=','XXX')"/>
The value 'XXX' should be replaced by:

• 'DEV' in development environment
• 'ASS' in assembly environment
• 'INT' in integration environment
• 'PROD' in production environment