I want to have an empty textarea

[Cecil Westerhof]

This is a piece of code from a xslt-file:

<xsl:template match="SMS">
<xsl:for-each select='.'>
<tr>
<td class = "inputDescription"><xsl:value-of select='.' />:</td>
<td><textarea class = "content" id = "{@id}" rows="5"
cols="50">#</textarea></td>
</tr>
</xsl:for-each>
</xsl:template>

When I remove the '#' to get an empty textare, the endtag is collapsed into
the begintag and all the HTML code after the textarea is displayed into the
textare. How can I get an empty textarea?

 

[roy axenov]

This is a piece of code from a xslt-file:

<xsl:template match="SMS">
<xsl:for-each select='.'>

As a side note, this is one of the silliest things I've
ever seen and a textbook case of magical thinking in
coding. It's not that I've never invoked foo to do bar
without understanding either foo or bar--I did, but after
being painfully bitten on my backside by that a few times
I just said no.

<tr>
<td class = "inputDescription"><xsl:value-of
select='.' />:</td>
<td><textarea class = "content" id = "{@id}"
rows="5" cols="50">#</textarea></td>
</tr>
</xsl:for-each>
</xsl:template>

When I remove the '#' to get an empty textare, the endtag
is collapsed into the begintag and all the HTML code
after the textarea is displayed into the textare. How can
I get an empty textarea?

You do get an empty textarea element, it is just being
serialized as XML. There are a few possible causes for
this:

- you might've forgotten to set <xslutput method="html"
... /> in your transformation. If this is the case, the
fix should be obvious.
- your XSLT processor doesn't grok <xslutput method=
"html" ... /> and blissfully serializes the resulting
tree as XML anyway. If this is the case, change your
XSLT processor.
- you're attempting to output XHTML1.0, but then serve it
as text/html anyway. Basically, XSLT processors couldn't
care less for workarounds described in W3C
recommendation to ensure backwards compatibility, and
without employing those workarounds you cannot serve
XHTML as text/html (and you shouldn't anyway if you care
for your sanity and general well-being one bit). If this
is the case, just output HTML4.01 instead (there might
be other solutions, but I won't go into that).

 

[Cecil Westerhof]

As a side note, this is one of the silliest things I've
ever seen and a textbook case of magical thinking in
coding. It's not that I've never invoked foo to do bar
without understanding either foo or bar--I did, but after
being painfully bitten on my backside by that a few times
I just said no.

I am quite new to xml and xslt. (It is my first try.) So how should I'll do
this?
Any pointers what documentation to use to learn working with xml and xslt? I
have 'XML in a Nutshell', but that is mere for reference instead of
learning I think.

You do get an empty textarea element, it is just being
serialized as XML. There are a few possible causes for
this:

- you might've forgotten to set <xslutput method="html"
... /> in your transformation. If this is the case, the
fix should be obvious.

This shall be it. I did not know about this. I need to go now, but when I
come back, I'll look it up.

 

[p.lepin]

I am quite new to xml and xslt. (It is my first try.) So
how should I'll do this?

Well, you just don't need that for-each. It doesn't really
do anything. As to why you don't need it: the first step is
understanding what for-each really is in XSLT. It's not a
'loop' - there are no loops in XSLT, - it's an inline
template together with its application to a nodeset. That
is:

<xsl:template match="foo">
<xsl:for-each select="bar">
<template/>
</xsl:for-each>
</xl:template>

....is almost-equivalent to:

<xsl:template match="foo">
<xsl:apply-templates select="bar"
mode="absolutely-globally-unique-mode"/>
</xsl:template>

<xsl:template match="@*|node()"
mode="absolutely-globally-unique-mode">
<template/>
</xsl:template>

Not try translating your code into this template-based
form:

<xsl:template match="SMS">
<xsl:apply-templates select="."
mode="absolutely-globally-unique-mode"/>
</xsl:template>

<xsl:template match="@*|node()"
mode="absolutely-globally-unique-mode">
<!-- whatever goes into the for-each -->
</xsl:template>

Now the flaw should be obvious. The first template
doesn't do anything, except invoking another template with
the same context node. Note that the template invoked is
guaranteed to always match, and not to be invoked by any
other template (otherwise this construct might make sense
under some circumstances).

Any pointers what documentation to use to learn working
with xml and xslt? I have 'XML in a Nutshell', but that
is mere for reference instead of learning I think.

References are good (although I've no idea if the one
you've mentioned *is* good). The group regulars will
probably have some good books to recommend, but in my
opinion the best way to learn is learning by doing and
understanding. With one caveat: don't try that in
production environments. Reading comp.text.xml and trying
to solve other people's problems is an excellent way to
learn.

XSL FAQ (google it) is an excellent if somewhat poorly
organized reading.

Just one hint: if you come from imperative programming
background, you'll need a paradigm shift. Until you learn
by heart that XSLT is a functional, template-based
language, you won't be any good at using it efficiently.

 

[Cecil Westerhof]

Well, you just don't need that for-each. It doesn't really
do anything. As to why you don't need it: the first step is
understanding what for-each really is in XSLT. It's not a
'loop' - there are no loops in XSLT, - it's an inline

Well I removed all the for-each and I did not see any difference. ;-}
I do not understand your explanation, but maybe when I take the time to
comprehend it ...

Why did the make the for-each when it is not usefull?

References are good (although I've no idea if the one
you've mentioned *is* good). The group regulars will
probably have some good books to recommend, but in my
opinion the best way to learn is learning by doing and
understanding. With one caveat: don't try that in
production environments. Reading comp.text.xml and trying
to solve other people's problems is an excellent way to
learn.

Expect to get a lot of questions in the newsgroup.
I must say that it is easy to get started with it. You can get transforming
xml to (inner) html quit fast. But the finer points will need time I am
afraid. :-}

XSL FAQ (google it) is an excellent if somewhat poorly
organized reading.

I'll look.

 

[Cecil Westerhof]

You do get an empty textarea element, it is just being
serialized as XML. There are a few possible causes for
this:

- you might've forgotten to set <xslutput method="html"
... /> in your transformation. If this is the case, the
fix should be obvious.
- your XSLT processor doesn't grok <xslutput method=
"html" ... /> and blissfully serializes the resulting
tree as XML anyway. If this is the case, change your
XSLT processor.

I did not use xslutput, but using it only complicated things. It made all
the tags uppercase and even added some tags. But the textarea kept being
generated the xml way. This was when using the firefox browser as
xslt-processor. When the processing is done on the server there is no
problem. But I like the processing to be done in the browser.
I decided to just use a '#' as a placeholder when I need an empty textarea
and delete the '#' with javascript. The only problem with this is that I
can not have a textarea filled with only a '#', but I think I can live with
that. :-}

 

[Joe Kesselman]

I do not understand your explanation, but maybe when I take the time to
comprehend it ...

Part of the problem is that Pavel gave you a slightly over-theoretical
explanation. It's correct, but not the information you really needed
right at this time.

Why did the make the for-each when it is not useful?

It is useful... when there's actually more than one node to iterate
over. The sloppiness in your example is that <xsl:for-each select=".">,
in specific, is a no-op. "Process all instances of 'the current node'"
is the same as just going ahead and processing the current node.
For-each is useful when you want to gather and process _multiple_
nodes/values.

In many cases, it actually is better to use an apply-templates call and
additional templates rather than a for-each. Learning when to use each
of those techniques is something that comes with experience.