Re: using Node variables with JSTL XML tags
hi Kris,
I think Xalan does the right thing evaluating
nodes = XPathAPI.selectNodeList(node, /@name);
starting from the document root. The real problem is not being able to
make *relative* XPath queries (without the starting slash). This seems
to be a major flaw in the JSTL spec.
Since node variables set with x:set (obviously) work, I looked at the
Jakarta impl sources to discover how x:set does the job. Basically it's
a big *hack*:
- x:set evaluates the XPath expression with Xalan the wraps the Nodelist
result into a org.apache.taglibs.standard.tag.common.xml.JSTLNodeList class.
- when x:out evaluates the XPath expression it checks for the $variable
type:
- if it is a JSTLNodeList containing 1 element of type
org.w3c.dom.Node, it creates a new Document, imports the Node and then
(here comes the hack) it prepends /* to the user specified XPath:
xpath=/* + xpath;
(org.apache.taglibs.standard.tag.common.xml.XPathUtil line 683)
- if the $variable is a org.w3.dom.Node it is used as it is as the
XPath Context as expected.
why this different treatment? obviously because of the Xalan behaviour
that Kris explained. I think the same hack should be applied to Node
variables so they work just like the impl-specific JSTLNodeList.
Any ideas? Any chance to let the developers know? They don't seem to be
on this list at all...
flavio
Kris Schneider wrote:
It seems like an issue with Xalan's XPath implementation. The Standard 1.1
taglib uses Xalan while Standard 1.0 uses Jaxen/SAXPath. Here's an example app
that mimics what it sounds like Flavio is trying to do:
import java.io.*;
import javax.xml.parsers.*;
import org.apache.xpath.*;
import org.w3c.dom.*;
import org.xml.sax.*;
public class XPathNode {
private static final String XML =
root name=\root\child name=\child\grandchild
name=\grandchild\/grandchild/child/root;
public static void main(String[] args) throws Exception {
DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
DocumentBuilder db = dbf.newDocumentBuilder();
Document doc = db.parse(new InputSource(new StringReader(XML)));
Element root = doc.getDocumentElement();
Node node = root.getFirstChild();
NodeList nodes = null;
nodes = XPathAPI.selectNodeList(doc, /root/child/@name);
printNodes(nodes);
nodes = XPathAPI.selectNodeList(node, /@name);
printNodes(nodes);
nodes = XPathAPI.selectNodeList(node, ./@name);
printNodes(nodes);
}
public static void printNodes(NodeList nodes) {
System.out.println(nodes:);
for (int i = 0, n = nodes.getLength(); i n; i++) {
Node node = nodes.item(i);
System.out.println(\t + node);
}
}
}
Which results in:
nodes:
name=child
nodes:
nodes:
name=child
Notice that for the XPath evaluation to work with node, I had to prepend .
to the expression. I'm not sure if it's possible to construct something similar
with the select attribute of JSTL's x tags...
Quoting Johnson, Chris [EMAIL PROTECTED]:
I see. I ran across a similar problem with JDOM Xpath, although they
solved it in a newer version, but totally screwed up the API and some
other stuff, so it killed the fix for me.
I had performance problems with the xml jstl tags (forEach), so I've
since moved on to using xslt. They're clearly not in a big hurry to fix
these (what we would consider big) problems.
Chris
-Original Message-
From: Flavio Tordini [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 08, 2004 10:36 AM
To: Tag Libraries Users List
Subject: Re: using Node variables with JSTL XML tags
hi chris,
thank you for your answer. The problem is i'm actually passing a *Node*
to the tag, not a Document. So I'd like to evaluate the XPath starting
from that Node, not from the root of the Document the Node belongs to.
I also tried:
x:forEach select=$node
x:out select=@name/
/x:forEach
and it works. But it's kind of a hack. I'm not searching for a
workaround, I need a clean solution since i'm working on a project that
aims to simplify JSP development with the aid of the JSTL + plus a
custom Servlet, and I cannot expect people to use this forEach hack.
flavio
Johnson, Chris wrote:
It seems that what 1.1 is doing is more correct.
How do you expect jstl to find your sub node without telling it how to
get there? That's how it works in directories on a computer (unix or
pc). The only way that I know of to go to a subnode without providing
the full path is by using the // operator, like:
select=$doc//subnode. Otherwise, the only way (that I know of) to
cd to a subnode, and therefore not have to give the full path is by
using x:forEach.
Chris
-Original Message-
From: Flavio Tordini [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 08, 2004 9:37 AM
To: Tag Libraries Users List
Subject: Re: using Node variables with JSTL XML tags
hi all,
In the list archive, I found that the same
Integer division question
Hi,
I have the following el code in a jsp:
length=${fn:length(myCollection) / 2}
where length is an attribute of type String (I can't change it to
Integer, this is an attribute of the Struts's iterate tag).
As fn:length() returns an integer and as 2 is an integer, I was
expecting that the value for length would be 6 for instance,
but I got 6.0.
Is it an intended feature of the division operator of the jstl/el or is
it a bug?
Pierre
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Integer division question
Per the JSP 2.0 Spec., both operands have been coerced to Double and then the
/ operator has been applied.
Quoting Pierre Scemla [EMAIL PROTECTED]:
Hi,
I have the following el code in a jsp:
length=${fn:length(myCollection) / 2}
where length is an attribute of type String (I can't change it to
Integer, this is an attribute of the Struts's iterate tag).
As fn:length() returns an integer and as 2 is an integer, I was
expecting that the value for length would be 6 for instance,
but I got 6.0.
Is it an intended feature of the division operator of the jstl/el or is
it a bug?
Pierre
--
Kris Schneider mailto:[EMAIL PROTECTED]
D.O.Tech http://www.dotech.com/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Integer division question
Thanks for your answer.
Does anybody know why they chose to do that instead of following the
behavior of the JLS?
Is there a way to force the conversion to an Integer?
Pierre
Kris Schneider wrote:
Per the JSP 2.0 Spec., both operands have been coerced to Double and then the
/ operator has been applied.
Quoting Pierre Scemla [EMAIL PROTECTED]:
Hi,
I have the following el code in a jsp:
length=${fn:length(myCollection) / 2}
where length is an attribute of type String (I can't change it to
Integer, this is an attribute of the Struts's iterate tag).
As fn:length() returns an integer and as 2 is an integer, I was
expecting that the value for length would be 6 for instance,
but I got 6.0.
Is it an intended feature of the division operator of the jstl/el or is
it a bug?
Pierre
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Integer division question
The EL was actually more inspired by ECMAScript and XPath than Java. In both
ECMAScript and XPath, division results in a floating-point value in accordance
with IEEE 754. If what you really want is a string representation of the number
without any fractional digits, you could use:
fmt:formatNumber var=... value=${fn:length(myCollection) / 2}
pattern=#/
Quoting Pierre Scemla [EMAIL PROTECTED]:
Thanks for your answer.
Does anybody know why they chose to do that instead of following the
behavior of the JLS?
Is there a way to force the conversion to an Integer?
Pierre
Kris Schneider wrote:
Per the JSP 2.0 Spec., both operands have been coerced to Double and then
the
/ operator has been applied.
Quoting Pierre Scemla [EMAIL PROTECTED]:
Hi,
I have the following el code in a jsp:
length=${fn:length(myCollection) / 2}
where length is an attribute of type String (I can't change it to
Integer, this is an attribute of the Struts's iterate tag).
As fn:length() returns an integer and as 2 is an integer, I was
expecting that the value for length would be 6 for instance,
but I got 6.0.
Is it an intended feature of the division operator of the jstl/el or is
it a bug?
Pierre
--
Kris Schneider mailto:[EMAIL PROTECTED]
D.O.Tech http://www.dotech.com/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: using Node variables with JSTL XML tags
I took a quick look at the code as well and it seems like what you're suggesting
should work. In other words, if it's not a Document and it's not a
JSTLNodeList, but it is a Node, do this:
Document doc = getDummyDocumentWithoutRoot();
Node importedNode = doc.importNode((Node)varObject, true);
doc.appendChild(importedNode);
boundDocument = doc;
if (whetherOrigXPath) {
xpath = /* + xpath;
}
instead of the current:
boundDocument = (Node)varObject;
At this point, the best thing to do would be to file a bug report:
http://issues.apache.org/bugzilla/enter_bug.cgi?product=Taglibs
Quoting Flavio Tordini [EMAIL PROTECTED]:
hi Kris,
I think Xalan does the right thing evaluating
nodes = XPathAPI.selectNodeList(node, /@name);
starting from the document root. The real problem is not being able to
make *relative* XPath queries (without the starting slash). This seems
to be a major flaw in the JSTL spec.
Since node variables set with x:set (obviously) work, I looked at the
Jakarta impl sources to discover how x:set does the job. Basically it's
a big *hack*:
- x:set evaluates the XPath expression with Xalan the wraps the Nodelist
result into a org.apache.taglibs.standard.tag.common.xml.JSTLNodeList class.
- when x:out evaluates the XPath expression it checks for the $variable
type:
- if it is a JSTLNodeList containing 1 element of type
org.w3c.dom.Node, it creates a new Document, imports the Node and then
(here comes the hack) it prepends /* to the user specified XPath:
xpath=/* + xpath;
(org.apache.taglibs.standard.tag.common.xml.XPathUtil line 683)
- if the $variable is a org.w3.dom.Node it is used as it is as the
XPath Context as expected.
why this different treatment? obviously because of the Xalan behaviour
that Kris explained. I think the same hack should be applied to Node
variables so they work just like the impl-specific JSTLNodeList.
Any ideas? Any chance to let the developers know? They don't seem to be
on this list at all...
flavio
Kris Schneider wrote:
It seems like an issue with Xalan's XPath implementation. The Standard 1.1
taglib uses Xalan while Standard 1.0 uses Jaxen/SAXPath. Here's an example
app
that mimics what it sounds like Flavio is trying to do:
import java.io.*;
import javax.xml.parsers.*;
import org.apache.xpath.*;
import org.w3c.dom.*;
import org.xml.sax.*;
public class XPathNode {
private static final String XML =
root name=\root\child name=\child\grandchild
name=\grandchild\/grandchild/child/root;
public static void main(String[] args) throws Exception {
DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
DocumentBuilder db = dbf.newDocumentBuilder();
Document doc = db.parse(new InputSource(new StringReader(XML)));
Element root = doc.getDocumentElement();
Node node = root.getFirstChild();
NodeList nodes = null;
nodes = XPathAPI.selectNodeList(doc, /root/child/@name);
printNodes(nodes);
nodes = XPathAPI.selectNodeList(node, /@name);
printNodes(nodes);
nodes = XPathAPI.selectNodeList(node, ./@name);
printNodes(nodes);
}
public static void printNodes(NodeList nodes) {
System.out.println(nodes:);
for (int i = 0, n = nodes.getLength(); i n; i++) {
Node node = nodes.item(i);
System.out.println(\t + node);
}
}
}
Which results in:
nodes:
name=child
nodes:
nodes:
name=child
Notice that for the XPath evaluation to work with node, I had to prepend
.
to the expression. I'm not sure if it's possible to construct something
similar
with the select attribute of JSTL's x tags...
Quoting Johnson, Chris [EMAIL PROTECTED]:
I see. I ran across a similar problem with JDOM Xpath, although they
solved it in a newer version, but totally screwed up the API and some
other stuff, so it killed the fix for me.
I had performance problems with the xml jstl tags (forEach), so I've
since moved on to using xslt. They're clearly not in a big hurry to fix
these (what we would consider big) problems.
Chris
-Original Message-
From: Flavio Tordini [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 08, 2004 10:36 AM
To: Tag Libraries Users List
Subject: Re: using Node variables with JSTL XML tags
hi chris,
thank you for your answer. The problem is i'm actually passing a *Node*
to the tag, not a Document. So I'd like to evaluate the XPath starting
from that Node, not from the root of the Document the Node belongs to.
I also tried:
x:forEach select=$node
x:out select=@name/
/x:forEach
and it works. But it's kind of a hack. I'm not searching for a
workaround, I need a clean solution since i'm working on a project that
aims to simplify JSP development with the
Re: using Node variables with JSTL XML tags
ok, i filed the bug:
http://issues.apache.org/bugzilla/show_bug.cgi?id=31147
Kris, thank you so much for your help!
flavio
Kris Schneider wrote:
I took a quick look at the code as well and it seems like what you're suggesting
should work. In other words, if it's not a Document and it's not a
JSTLNodeList, but it is a Node, do this:
Document doc = getDummyDocumentWithoutRoot();
Node importedNode = doc.importNode((Node)varObject, true);
doc.appendChild(importedNode);
boundDocument = doc;
if (whetherOrigXPath) {
xpath = /* + xpath;
}
instead of the current:
boundDocument = (Node)varObject;
At this point, the best thing to do would be to file a bug report:
http://issues.apache.org/bugzilla/enter_bug.cgi?product=Taglibs
Quoting Flavio Tordini [EMAIL PROTECTED]:
hi Kris,
I think Xalan does the right thing evaluating
nodes = XPathAPI.selectNodeList(node, /@name);
starting from the document root. The real problem is not being able to
make *relative* XPath queries (without the starting slash). This seems
to be a major flaw in the JSTL spec.
Since node variables set with x:set (obviously) work, I looked at the
Jakarta impl sources to discover how x:set does the job. Basically it's
a big *hack*:
- x:set evaluates the XPath expression with Xalan the wraps the Nodelist
result into a org.apache.taglibs.standard.tag.common.xml.JSTLNodeList class.
- when x:out evaluates the XPath expression it checks for the $variable
type:
- if it is a JSTLNodeList containing 1 element of type
org.w3c.dom.Node, it creates a new Document, imports the Node and then
(here comes the hack) it prepends /* to the user specified XPath:
xpath=/* + xpath;
(org.apache.taglibs.standard.tag.common.xml.XPathUtil line 683)
- if the $variable is a org.w3.dom.Node it is used as it is as the
XPath Context as expected.
why this different treatment? obviously because of the Xalan behaviour
that Kris explained. I think the same hack should be applied to Node
variables so they work just like the impl-specific JSTLNodeList.
Any ideas? Any chance to let the developers know? They don't seem to be
on this list at all...
flavio
Kris Schneider wrote:
It seems like an issue with Xalan's XPath implementation. The Standard 1.1
taglib uses Xalan while Standard 1.0 uses Jaxen/SAXPath. Here's an example
app
that mimics what it sounds like Flavio is trying to do:
import java.io.*;
import javax.xml.parsers.*;
import org.apache.xpath.*;
import org.w3c.dom.*;
import org.xml.sax.*;
public class XPathNode {
private static final String XML =
root name=\root\child name=\child\grandchild
name=\grandchild\/grandchild/child/root;
public static void main(String[] args) throws Exception {
DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
DocumentBuilder db = dbf.newDocumentBuilder();
Document doc = db.parse(new InputSource(new StringReader(XML)));
Element root = doc.getDocumentElement();
Node node = root.getFirstChild();
NodeList nodes = null;
nodes = XPathAPI.selectNodeList(doc, /root/child/@name);
printNodes(nodes);
nodes = XPathAPI.selectNodeList(node, /@name);
printNodes(nodes);
nodes = XPathAPI.selectNodeList(node, ./@name);
printNodes(nodes);
}
public static void printNodes(NodeList nodes) {
System.out.println(nodes:);
for (int i = 0, n = nodes.getLength(); i n; i++) {
Node node = nodes.item(i);
System.out.println(\t + node);
}
}
}
Which results in:
nodes:
name=child
nodes:
nodes:
name=child
Notice that for the XPath evaluation to work with node, I had to prepend
.
to the expression. I'm not sure if it's possible to construct something
similar
with the select attribute of JSTL's x tags...
Quoting Johnson, Chris [EMAIL PROTECTED]:
I see. I ran across a similar problem with JDOM Xpath, although they
solved it in a newer version, but totally screwed up the API and some
other stuff, so it killed the fix for me.
I had performance problems with the xml jstl tags (forEach), so I've
since moved on to using xslt. They're clearly not in a big hurry to fix
these (what we would consider big) problems.
Chris
-Original Message-
From: Flavio Tordini [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 08, 2004 10:36 AM
To: Tag Libraries Users List
Subject: Re: using Node variables with JSTL XML tags
hi chris,
thank you for your answer. The problem is i'm actually passing a *Node*
to the tag, not a Document. So I'd like to evaluate the XPath starting
from that Node, not from the root of the Document the Node belongs to.
I also tried:
x:forEach select=$node
x:out select=@name/
/x:forEach
and it works. But it's kind of a hack. I'm not searching for a
workaround, I need a clean solution since i'm working on a project that
aims to simplify JSP development with the aid of the JSTL + plus a
custom Servlet, and I cannot expect people to use this forEach hack.
flavio
Dynamic variable names
Greetings,
I have incoming params from another page that I want to cycle through,
with one attribute of them that changes.
I want to cycle through all the attributes of type color, basically
checking if the 'old' matches the 'new' for that attribute.
The params look like this old/new-color-attribute name eg: old-B-blade
How would I just drop in the current loop color, a la:
${param.old-current-loop-color-attribute}/ ?
Thanks,
- Nic.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: using Node variables with JSTL XML tags
Hi Flavio,
I've seen the discussion on the list related to the XPath integration. I
agree the implementation is rather messy.
I'm going to evaluate the fix, verify it, and if everything works apply
it to the JSTL workspace.
Thanks,
Justyna
Flavio Tordini wrote:
hi Kris,
I think Xalan does the right thing evaluating
nodes = XPathAPI.selectNodeList(node, /@name);
starting from the document root. The real problem is not being able to
make *relative* XPath queries (without the starting slash). This seems
to be a major flaw in the JSTL spec.
Since node variables set with x:set (obviously) work, I looked at the
Jakarta impl sources to discover how x:set does the job. Basically it's
a big *hack*:
- x:set evaluates the XPath expression with Xalan the wraps the Nodelist
result into a org.apache.taglibs.standard.tag.common.xml.JSTLNodeList
class.
- when x:out evaluates the XPath expression it checks for the $variable
type:
- if it is a JSTLNodeList containing 1 element of type
org.w3c.dom.Node, it creates a new Document, imports the Node and then
(here comes the hack) it prepends /* to the user specified XPath:
xpath=/* + xpath;
(org.apache.taglibs.standard.tag.common.xml.XPathUtil line 683)
- if the $variable is a org.w3.dom.Node it is used as it is as the
XPath Context as expected.
why this different treatment? obviously because of the Xalan behaviour
that Kris explained. I think the same hack should be applied to Node
variables so they work just like the impl-specific JSTLNodeList.
Any ideas? Any chance to let the developers know? They don't seem to be
on this list at all...
flavio
Kris Schneider wrote:
It seems like an issue with Xalan's XPath implementation. The Standard
1.1
taglib uses Xalan while Standard 1.0 uses Jaxen/SAXPath. Here's an
example app
that mimics what it sounds like Flavio is trying to do:
import java.io.*;
import javax.xml.parsers.*;
import org.apache.xpath.*;
import org.w3c.dom.*;
import org.xml.sax.*;
public class XPathNode {
private static final String XML =
root name=\root\child name=\child\grandchild
name=\grandchild\/grandchild/child/root;
public static void main(String[] args) throws Exception {
DocumentBuilderFactory dbf =
DocumentBuilderFactory.newInstance();
DocumentBuilder db = dbf.newDocumentBuilder();
Document doc = db.parse(new InputSource(new StringReader(XML)));
Element root = doc.getDocumentElement();
Node node = root.getFirstChild();
NodeList nodes = null;
nodes = XPathAPI.selectNodeList(doc, /root/child/@name);
printNodes(nodes);
nodes = XPathAPI.selectNodeList(node, /@name);
printNodes(nodes);
nodes = XPathAPI.selectNodeList(node, ./@name);
printNodes(nodes);
}
public static void printNodes(NodeList nodes) {
System.out.println(nodes:);
for (int i = 0, n = nodes.getLength(); i n; i++) {
Node node = nodes.item(i);
System.out.println(\t + node);
}
}
}
Which results in:
nodes:
name=child
nodes:
nodes:
name=child
Notice that for the XPath evaluation to work with node, I had to
prepend .
to the expression. I'm not sure if it's possible to construct
something similar
with the select attribute of JSTL's x tags...
Quoting Johnson, Chris [EMAIL PROTECTED]:
I see. I ran across a similar problem with JDOM Xpath, although they
solved it in a newer version, but totally screwed up the API and some
other stuff, so it killed the fix for me.
I had performance problems with the xml jstl tags (forEach), so I've
since moved on to using xslt. They're clearly not in a big hurry to fix
these (what we would consider big) problems.
Chris
-Original Message-
From: Flavio Tordini [mailto:[EMAIL PROTECTED] Sent: Wednesday,
September 08, 2004 10:36 AM
To: Tag Libraries Users List
Subject: Re: using Node variables with JSTL XML tags
hi chris,
thank you for your answer. The problem is i'm actually passing a
*Node* to the tag, not a Document. So I'd like to evaluate the XPath
starting from that Node, not from the root of the Document the Node
belongs to.
I also tried:
x:forEach select=$node
x:out select=@name/
/x:forEach
and it works. But it's kind of a hack. I'm not searching for a
workaround, I need a clean solution since i'm working on a project
that aims to simplify JSP development with the aid of the JSTL + plus
a custom Servlet, and I cannot expect people to use this forEach hack.
flavio
Johnson, Chris wrote:
It seems that what 1.1 is doing is more correct.
How do you expect jstl to find your sub node without telling it how to
get there? That's how it works in directories on a computer (unix
or pc). The only way that I know of to go to a subnode without
providing
the full path is by using the // operator, like:
select=$doc//subnode. Otherwise, the only way (that I know of) to
cd to a subnode, and therefore not have to give the full path is
by
