Rückgabewert einer Funktion in XSL als glob. Variable festlegen

[defiant2369]

Hallo,

ich habe innerhalb eines XSL-Dokuments ein JavaScript mit einer Funktion, welches mir als Rückgabewert 'true' oder 'false' liefert. Diese Werte möchte ich gerne als gloable Variable festlegen, damit ich sie im weteren Verlauf des Dokuments abfragen kann mittels "when test".
Geht sowas überhaupt?

Hier das JavaScript:

function is200series ()  
{  
    if (navigator.userAgent.search(/4(0[89]|1[01])/)>0)  
    {return true;}  
    else {return false;}  
}  

Als Variable wollte ich das so festlegen:

<xsl:variable name="C200">  
....  
</xsl:variable>

Dei Funktion selber rufe ich im BODY mittels 'onload' auf.

[Kai345]

[latex]Mae  govannen![/latex]

Sorry, zu deinem eigentlichen Problem kann ich leider nichts sagen, aber mir ist die JS-Funktion aufgefallen. Explizite Rückgabe von boolschen Werten in Abhängigkeit einer Bedingung ist nicht notwendig

function is200series ()

{
    if (navigator.userAgent.search(/4(0[89]|1[01])/)>0)
    {return true;}
    else {return false;}
}

  
entspricht  
  
~~~javascript
function is200series ()  
{  
    return (navigator.userAgent.search(/4(0[89]|1[01])/)>0);  
}

(Die Klammern um die Bedingung kann man auch noch weglassen, ich schreibe sie wegen der besseren Les- und Erfassbarkeit des Codes.)

Stur lächeln und winken, Männer!
Kai

[dedlfix]

Hi!

Sorry, zu deinem eigentlichen Problem kann ich leider nichts sagen,

Aber ich vielleicht. Variablen in XSL sind quasi Konstanten. Ihr Wert lässt sich nur ein einziges Mal und an einer einzigen Stelle festlegen. Deswegen kann man bedingte Inhalte nicht à la

if (bedingung)
    <var name=foo>x</var>
  else
    <var name=foo>y</var>

notieren, sondern nur nach dem Prinzip

<var name=foo>
    if (bedingung)
      x
    else
      y
  </var>

Wie auch immer Javascript ein Ergebnis an XSL zurückliefert, es muss innerhalb von xsl:variable...</xsl:variable> geschehen.

return (navigator.userAgent.search(/4(0[89]|1[01])/)>0);
(Die Klammern um die Bedingung kann man auch noch weglassen, ich schreibe sie wegen der besseren Les- und Erfassbarkeit des Codes.)

Für mich wäre das keine Verbesserung sondern eine Verschlechterung. Klammern, die nicht zwingend aus syntaktischen Gründen gesetzt werden müssen, wie zum Einklammern der if-Bedingung, dienen der Priorisierung eines Teilausdrucks entgegen der Operatorenrangfolge. Ich sehe da also eine Klammer und fange an, nach dem priorisierten Teil zu suchen, und ... April, April ... keiner da, nur ein weiteres Klammernpaar, das bei der Findung von Klammern-Zugehörigkeiten zusätzlich berücksichtigt werden muss.

Lo!

[Kai345]

[latex]Mae  govannen![/latex]

return (navigator.userAgent.search(/4(0[89]|1[01])/)>0);
(Die Klammern um die Bedingung kann man auch noch weglassen, ich schreibe sie wegen der besseren Les- und Erfassbarkeit des Codes.)

Für mich wäre das keine Verbesserung sondern eine Verschlechterung. Klammern, die nicht zwingend aus syntaktischen Gründen gesetzt werden müssen, wie zum Einklammern der if-Bedingung, dienen der Priorisierung eines Teilausdrucks entgegen der Operatorenrangfolge. Ich sehe da also eine Klammer und fange an, nach dem priorisierten Teil zu suchen, und ... April, April ... keiner da, nur ein weiteres Klammernpaar, das bei der Findung von Klammern-Zugehörigkeiten zusätzlich berücksichtigt werden muss.

Das ist eine Sache der persönlichen Präferenz und des bevorzugten Programmier-Stils, insofern könnte man da ewig diskutieren.

Bei _mir_ ist es so, wenn ich lese

return navigator.userAgent.search(/4(0[89]|1[01])/)>0;

kann es passieren, daß mein Eyes-to-Brain-Parser nur return navigator.userAgent.search(/4(0[89]|1[01])/) liest. Bei return (... ist die Wahrscheinlichkeit geringer, denn dann schaue ich genauer hin.

Allerdings wäre bei meinem Programmierstil das Scheitern etwas weniger wahrscheinlich, da ich zwingend vor und hinter jedem Operator ein Leerzeichen setze.

Stur lächeln und winken, Männer!
Kai

[molily]

kann es passieren, daß mein Eyes-to-Brain-Parser nur return navigator.userAgent.search(/4(0[89]|1[01])/) liest. Bei return (... ist die Wahrscheinlichkeit geringer, denn dann schaue ich genauer hin.

Allerdings wäre bei meinem Programmierstil das Scheitern etwas weniger wahrscheinlich, da ich zwingend vor und hinter jedem Operator ein Leerzeichen setze.

Deshalb würde ich der Einfachheit halber vorschlagen:

return /4(0[89]|1[01])/.test(navigator.userAgent);

;)

(Das macht allerdings etwas anderes als search() > 0, wobei ich vermute, dass > -1 gemeint war, daher obiger Vorschlag.)

Mathias

[defiant2369]

Hi!

Sorry, zu deinem eigentlichen Problem kann ich leider nichts sagen,

Aber ich vielleicht. Variablen in XSL sind quasi Konstanten. Ihr Wert lässt sich nur ein einziges Mal und an einer einzigen Stelle festlegen. Deswegen kann man bedingte Inhalte nicht à la

if (bedingung)
    <var name=foo>x</var>
  else
    <var name=foo>y</var>

notieren, sondern nur nach dem Prinzip

<var name=foo>
    if (bedingung)
      x
    else
      y
  </var>

Wie auch immer Javascript ein Ergebnis an XSL zurückliefert, es muss innerhalb von xsl:variable...</xsl:variable> geschehen.

OK, Danke schonmal für den Hinweis.
Also müßte ich das Script innerhalb der xsl:variable ausführen oder wie muß ich mir das vorstellen?

[dedlfix]

Hi!

Wie auch immer Javascript ein Ergebnis an XSL zurückliefert, es muss innerhalb von xsl:variable...</xsl:variable> geschehen.
Also müßte ich das Script innerhalb der xsl:variable ausführen oder wie muß ich mir das vorstellen?

Da ich nicht weiß, wie Javascript mit XSL zusammenarbeitet, kann ich das nicht genau beantworten. Wenn es ähnlich wie bei PHP funktioniert, also XSL-Code mit eingebauten Javascript-Code-Inseln, dann: ja, das Script kann innerhalb des xsl:variable-Elements stehen. Jedenfalls muss das Ergebnis dort drin landen.

Lo!