There is of course an entirely different approach which is possible...
Have your XSP capture the required input parameters and construct some output XML containing the data you need. Then you have some added flexibility by doing it with perl. I've found that generally thats the better overall technique from a standpoint of general web application structure, since you probably want to validate and scrub those inputs anyway (ie maybe for purposes of avoiding XSS attacks etc.
Kjetil Kjernsmo wrote:
On torsdag 8. juli 2004, 16:59, Michael A Nachbaur wrote:
Is that line really necessary....?
Not really. It mainly can be used to supply a default, non-empty, value. So, if you say:
<xsl:param name="foo" select="'NULL'"/>
and then later say
<xsl:if test="$foo = 'NULL'> # No value was supplied </xsl:if>
that'd do the trick in determining if simply an empty string was
supplied.
Ah, that's a good idea!
But I bumped into something funny, it seems like the line in fact is needed for some applications:
My templates now look like this: <xsl:param name="title" select="''"/>
<xsl:template match="//val:[EMAIL PROTECTED]'title']">
<xsl:if test="$title = ''">
<xsl:value-of select="//story:story/story:title"/> </xsl:if>
<xsl:if test="not($title = '')">
<xsl:value-of select="$title"/> </xsl:if> </xsl:template>
<xsl:param name="minicontent" select="''"/>
<xsl:template match="//val:[EMAIL PROTECTED]'minicontent']">
<xsl:if test="$minicontent = ''">
<xsl:value-of select="//story:story/story:minicontent"/> </xsl:if>
<xsl:if test="not($minicontent = '')">
<xsl:value-of select="$minicontent"/> </xsl:if> </xsl:template>
This works as intended. But if I comment out the "variable declaration" in the xsl:param element, I get an Internal Server Error, and the error message:
runtime error: file /news/insert-values-edit.xsl element if
unregistered variable title
...but it happens only if title is not supplied at all. Which means, it is more or less needed for robustness.
The two above templates aren't a very nice display of Laziness, as you can see... And I need a dozen of those unless I'm able to rewrite it, so that's the other, original question... The variable name is available to the template in //val:[EMAIL PROTECTED], but the problem is making that a variable name... It itches terribly...
Cheers,
Kjetil
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
