hi,
does anyone have a clue why an <if> inside the <ul> block on /download/index.xml never shows?
<if variable='var.winstable'>works as expected</if> <ul> <li><a href="/download/pub/pike/latest-stable/"> <b>Latest stable binary version</b> (&var.stable;)</a><br/> Binaries for the most recent release are made available as we manage to produce and quality control them. Usually made for at least Linux x86, Linux ppc and Solaris sparc. For more info, read the <a href="notes/&var.stable;.xml">release notes</a>.</li> <if variable='var.winstable'>this if seems never true</if> </ul>
if that would work then the simple existance of /download/currentwinstable.txt could determine wether a seperate "windows" paragraph is visible or not
greetings, martin.
Well, wouldn't lack of <nocache> cause equal overcaching in the first <if> statement?
Less likely but also possible is that his browser follows the HTML DTD and rejects anything but <li> elements inside <ul>. Having random text as an <ul> child is semantically incorrect, so try View Source in the browser to see if it's there after all.
Judging by the content, I'd say you are working with the pike site, whose templates are often written not to expect rxml content, in this case with an <ul> rule:
<xsl:template match="ul"> <xsl:call-template name="ul"> <xsl:with-param name="contents"> <xsl:apply-templates select="li"/> </xsl:with-param> </xsl:call-template> </xsl:template>
It's probably fixable in /templates/tags.xsl with lots of itchy brain scratching. I think server side xslt causes more pain than joy at the pike site today, though expunging it unfortunately takes quite a bit of work. A site overhaul with mostly html and css would totally rock, but I can't imagine anyone having the time and incitement to do it.
On Sat, Nov 11, 2006 at 12:15:00PM +0000, Johan Sundstr�m (Achtung Liebe!) @ Pike (-) developers forum wrote:
Judging by the content, I'd say you are working with the pike site,
that's why it says "pike site" in the subject ;-)
whose templates are often written not to expect rxml content, in this case with an <ul> rule:
ahhh.
<xsl:apply-templates select="li"/>
in this case it boils down to the interaction of xslt with rxml. i though that rxml would come first. but i guess not. hmmm...
greetings, martin.
Judging by the content, I'd say you are working with the pike site,
that's why it says "pike site" in the subject ;-)
Oh, I didn't notice, but things worked out fairly well anyway. :-)
in this case it boils down to the interaction of xslt with rxml. i though that rxml would come first. but i guess not.
No; it's two separate passes, xslt transformation run first. Xslt does a much better job of transforming dumb xml formats than free form rxml (but I didn't know that at the time we were setting up those site).
pike-devel@lists.lysator.liu.se
-
Johan Sundstr�m (Achtung Liebe!) ＠ Pike (-) developers forum -
Jonas Walld�n ＠ Pike developers forum
-
Martin Baehr -
Martin Bähr
-
Martin Nilsson (Opera Mini - AFK!) ＠ Pike (-) developers forum