[standard] Wrong behaviour of x:out inside x:forEach

2004-07-09 Thread Flavio Tordini
hi all,
inside a x:forEach loop, i put an x:out that evaluates an XPath 
expression on a document which is not same of the x:forEach.
The x:out seems to behave strangely. Take a look at following JSP:

===
%@ taglib prefix=x uri=http://java.sun.com/jsp/jstl/xml; %
%@ taglib prefix=c uri=http://java.sun.com/jsp/jstl/core; %
c:import url=sample.xml varReader=r
  x:parse var=sample doc=${r}/
/c:import
x:forEach select=$sample/sample/link
  c:set var=link
x:out select=@href/
  /c:set
  c:import url=${link} varReader=r2
x:parse var=sample2 doc=${r2}/
  /c:import
  !-- *** this does not work *** --
  x:out select=$sample2/sample2/text/
  !-- this does work, but i think it is not correct --
  x:out select=$sample2/text/
/x:forEach
==
sample.xml:
==
sample
  link href=sample2.xml/
/sample
==
sample2.xml:
==
sample2
  textthis is just a test!/text
/sample2
==
I'm using JSTL 1.1, Jakarta Taglib Standard 1.1.0, Tomcat 5.0.25 (same 
problem on both linux and windows)
Any suggestions? Is this a bug?

flavio
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


using Node variables with JSTL XML tags

2004-09-08 Thread Flavio Tordini
hi all,
I'm experimenting with the JSTL XML tags. I have a org.w3c.dom.Node 
variable and I'm trying to use the JSTL with it. Something like:

x:out select=$node/@name/
The odd thing is that the XPath expression is evaluated relative the 
document root, not to the specified node. The following works:

x:out select=$node/full/path/to/node/@name/
I cannot find an explanation in the JSTL 1.1 spec. The only thing I 
found is in section 11.1.3:

An XPath expression must also treat variables that resolve to 
implementations of standard DOM interfaces as representing nodes of the 
type bound to that interface by the DOM specification.

Is this behaviour by design? Is it compliant with the spec?
Thank you in advance,
flavio
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: using Node variables with JSTL XML tags

2004-09-08 Thread Flavio Tordini
hi helios,
Unfortunately it does not work. it gives the following error:
Illegal argument evaluating XPath expression /*: 
java.lang.IllegalArgumentException: Node must be non-null for 
getDTMHandleFromNode

Clearly the JSTL implementation is trying to use [EMAIL PROTECTED] as the 
variable name. So this is not the way to go.

flavio
Helios Alonso wrote:
Hmm... I don't know too much about xtags but try:
[EMAIL PROTECTED] (without the bar)
:-)
Hope it helps.
At 10:36 08/09/2004 +0200, you wrote:
hi all,
I'm experimenting with the JSTL XML tags. I have a org.w3c.dom.Node 
variable and I'm trying to use the JSTL with it. Something like:

x:out select=$node/@name/
The odd thing is that the XPath expression is evaluated relative the 
document root, not to the specified node. The following works:

x:out select=$node/full/path/to/node/@name/
I cannot find an explanation in the JSTL 1.1 spec. The only thing I 
found is in section 11.1.3:

An XPath expression must also treat variables that resolve to 
implementations of standard DOM interfaces as representing nodes of 
the type bound to that interface by the DOM specification.

Is this behaviour by design? Is it compliant with the spec?
Thank you in advance,
flavio
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: using Node variables with JSTL XML tags

2004-09-08 Thread Flavio Tordini
hi all,
In the list archive, I found that the same question has been asked in 
June e never answered:

http://www.mail-archive.com/[EMAIL PROTECTED]/msg07315.html
should I post to the dev mailing list?
should I report a bug?
please someone answer!
flavio
Flavio Tordini wrote:
hi all,
I'm experimenting with the JSTL XML tags. I have a org.w3c.dom.Node 
variable and I'm trying to use the JSTL with it. Something like:

x:out select=$node/@name/
The odd thing is that the XPath expression is evaluated relative the 
document root, not to the specified node. The following works:

x:out select=$node/full/path/to/node/@name/
I cannot find an explanation in the JSTL 1.1 spec. The only thing I 
found is in section 11.1.3:

An XPath expression must also treat variables that resolve to 
implementations of standard DOM interfaces as representing nodes of the 
type bound to that interface by the DOM specification.

Is this behaviour by design? Is it compliant with the spec?
Thank you in advance,
flavio
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: using Node variables with JSTL XML tags

2004-09-08 Thread Flavio Tordini
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 question has been asked in 
June e never answered:

http://www.mail-archive.com/[EMAIL PROTECTED]/msg07315.htm
l
should I post to the dev mailing list?
should I report a bug?
please someone answer!
flavio
Flavio Tordini wrote:
hi all,
I'm experimenting with the JSTL XML tags. I have a org.w3c.dom.Node
variable and I'm trying to use the JSTL with it. Something like:
x:out select=$node/@name/
The odd thing is that the XPath expression is evaluated relative the
document root, not to the specified node. The following works:
x:out select=$node/full/path/to/node/@name/
I cannot find an explanation in the JSTL 1.1 spec. The only thing I
found is in section 11.1.3:
An XPath expression must also treat variables that resolve to
implementations of standard DOM interfaces as representing nodes of
the 

type bound to that interface by the DOM specification.
Is this behaviour by design? Is it compliant with the spec?
Thank you in advance,
flavio
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: using Node variables with JSTL XML tags

2004-09-09 Thread Flavio Tordini
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

Re: using Node variables with JSTL XML tags

2004-09-09 Thread Flavio Tordini
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

problem with fmt:formatDate

2004-10-14 Thread Flavio Tordini
Hi all,
I'm using the fmt:formatDate tag and I discovered a strange behaviour:

When a JSP is requested without specifying the Accept-Language HTTP header 
and no locale has been explicitly set in the JSP, the date is not formatted 
and the result of Date.toString() is returned instead.

I checked the JSTL spec, this is what it says to do when the algorithm cannot 
find a Locale:
If no match is found after the above two steps, it is up to the formatting 
action to take a corrective action.
I don't know what corrective action means in this context, but I think that 
using the default JVM locale would be much better than toString().

here's a sample JSP, you can test it with curl or wget:

%@ taglib prefix=fmt uri=http://java.sun.com/jsp/jstl/fmt; %
jsp:useBean id=now class=java.util.Date /
fmt:formatDate value=${now} pattern=/

regards,
flavio tordini


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: problem with fmt:formatDate

2004-10-14 Thread Flavio Tordini
hi Kris,
thank you for your answer! I'm sorry I didn't find that statement before 
posting. Ok,  it's 100% spec compliant... let's hope the spec will be changed 
in the future. It would also be backwards-compatible since noone relies on 
the *absence* of a HTTP request header to determine the date format anyway.

IMHO the problem is someone (like me :) could write:

%@ taglib prefix=c uri=http://java.sun.com/jsp/jstl/core; %
%@ taglib prefix=fmt uri=http://java.sun.com/jsp/jstl/fmt; %
jsp:useBean id=now class=java.util.Date /
fmt:formatDate var=currentYear value=${now} pattern=/
c:forEach begin=1976 end=${currentYear} varStatus=status
  ${status.index}
/c:forEach

and see this:

javax.servlet.jsp.el.ELException: An exception occured trying to convert 
String Thu Oct 14 14:59:29 CEST 2004 to type java.lang.Integer

flavio

On Thursday 14 October 2004 13:33, Kris Schneider wrote:
 I'm not arguing whether or not it's the *best* thing to do, but the JSTL
 1.1 Spec. includes:

 9.9 fmt:formatDate
 ..
 Null  Error Handling
 - If value is null or empty, nothing is written to the current JspWriter
 object and the scoped variable is removed if it is specified (see
 attributes var and scope).
 - If timeZone is null or empty, it is handled as if it was missing.
 - If this action fails to determine a formatting locale, it uses
 java.util.Date.toString() as the output format.

 So, it looks like it's at least behaving according to the spec...

 Quoting Flavio Tordini [EMAIL PROTECTED]:
  Hi all,
  I'm using the fmt:formatDate tag and I discovered a strange behaviour:
 
  When a JSP is requested without specifying the Accept-Language HTTP
  header
 
  and no locale has been explicitly set in the JSP, the date is not
  formatted and the result of Date.toString() is returned instead.
 
  I checked the JSTL spec, this is what it says to do when the algorithm
  cannot
 
  find a Locale:
  If no match is found after the above two steps, it is up to the
  formatting action to take a corrective action.
  I don't know what corrective action means in this context, but I think
  that
 
  using the default JVM locale would be much better than toString().
 
  here's a sample JSP, you can test it with curl or wget:
 
  %@ taglib prefix=fmt uri=http://java.sun.com/jsp/jstl/fmt; %
  jsp:useBean id=now class=java.util.Date /
  fmt:formatDate value=${now} pattern=/
 
  regards,
  flavio tordini

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]