RE: JSTL for Maps?

2002-10-18 Thread Karr, David

> -Original Message-
> From: Wendy Smoak [mailto:Wendy.Smoak@;asu.edu]
> Sent: Friday, October 18, 2002 4:56 PM

> > Section A.3.4 of the specification talks about using the 
> "[]" operator to
> > access maps.  From this, you can see that your EL 
> expression would be
> > "${preferredNames[staffMember]}".  If you're using 
> Struts-EL, you can just
> > use that as your "value" value on your "html-el:text" element.
> 
> I can't use the html-el tag for this, because then Struts wants to
> pre-populate the text box and will complain that there are no
> getJunk/getJunk methods in my ActionForm.  If I could figure 

Huh?  I don't understand.  Don't you want to prepopulate the text field with
the value of your "value" attribute?  If the "value" attribute is set, it
doesn't read a bean value from the "property" attribute.  How does
"html-el:text" not work for you?

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




RE: JSTL for Maps?

2002-10-18 Thread Wendy Smoak
> Section A.3.4 of the specification talks about using the "[]" operator to
> access maps.  From this, you can see that your EL expression would be
> "${preferredNames[staffMember]}".  If you're using Struts-EL, you can just
> use that as your "value" value on your "html-el:text" element.

I can't use the html-el tag for this, because then Struts wants to
pre-populate the text box and will complain that there are no
getJunk/getJunk methods in my ActionForm.  If I could figure out how to make
something that *looks* like a text-box (with CSS?), I'd do that instead.
But lacking that knowledge, a read-only text box is what I'm using.

Thanks for the syntax help.  Looks like I need the c:out tag:

"/>

(This is starting to look like Perl!)

-- 
Wendy Smoak 
http://sourceforge.net/projects/unidbtags 



RE: JSTL for Maps?

2002-10-18 Thread Karr, David
Section A.3.4 of the specification talks about using the "[]" operator to
access maps.  From this, you can see that your EL expression would be
"${preferredNames[staffMember]}".  If you're using Struts-EL, you can just
use that as your "value" value on your "html-el:text" element.

> -Original Message-
> From: Wendy Smoak [mailto:Wendy.Smoak@;asu.edu]
> Sent: Friday, October 18, 2002 3:46 PM
> 
> I've poked around the Standard Taglib documentation, and 
> asked Google, but
> so far I can't find what I need.
> 
> I have a Hashtable in session scope.  I have a String in page 
> scope that is
> the key to something in the Hashtable.  What tag can get the 
> value out of
> the Hashtable for me?
> 
> I don't think it matters, but I'm using Struts.  (Not for 
> this tag-- I don't
> care about the value, I just need to display it in a white box.)
> 
> Currently I'm doing this, which just puts the 'key' into the 
> readonly text
> box.
> 
>  value=""/>
> 
> The Map in session scope is called preferredNames, so somehow 
> I need to call
> 
>preferredNames.get(${staffMember});
> 
> Any takers?  Thanks!
> 
> -- 
> Wendy Smoak
> http://sourceforge.net/projects/unidbtags 
> 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




JSTL for Maps?

2002-10-18 Thread Wendy Smoak

I've poked around the Standard Taglib documentation, and asked Google, but
so far I can't find what I need.

I have a Hashtable in session scope.  I have a String in page scope that is
the key to something in the Hashtable.  What tag can get the value out of
the Hashtable for me?

I don't think it matters, but I'm using Struts.  (Not for this tag-- I don't
care about the value, I just need to display it in a white box.)

Currently I'm doing this, which just puts the 'key' into the readonly text
box.

"/>

The Map in session scope is called preferredNames, so somehow I need to call

   preferredNames.get(${staffMember});

Any takers?  Thanks!

-- 
Wendy Smoak
http://sourceforge.net/projects/unidbtags 



RE: Help with JSTL and Tomcat 4.0.4 - Tomcat Sax Parser Error in Reading web.xml

2002-10-18 Thread Rob Swan
David,

Thanks for answering.  I feel pretty stupid.  I made 2 changes at the
same time and incorrectly thought that removing the taglibs eliminated
the problem.

No so...

Sorry for the spam.

Rob Swan
Director of Operations
Object Publishing Software
Phone:  206-545-6851 ext 128
Email: [EMAIL PROTECTED]  


-Original Message-
From: Karr, David [mailto:david.karr@;attws.com] 
Sent: Friday, October 18, 2002 1:14 PM
To: 'Tag Libraries Users List'
Subject: RE: Help with JSTL and Tomcat 4.0.4 - Tomcat Sax Parser Error
in Reading web.xml


I would want to see lines 1-20 of your web.xml file.  The error is on
line 17, and has to do with the "servlet" element.  It doesn't appear to
have anything to do with taglibs.

> -Original Message-
> From: Rob Swan [mailto:robswan@;objectpublish.com]
> Sent: Friday, October 18, 2002 1:32 PM
> To: 'Tag Libraries Users List'
> Subject: Help with JSTL and Tomcat 4.0.4 - Tomcat Sax Parser Error in 
> Reading web.xml
> 
> 
> I am trying to convert from Tomcat 3.2.1 to 4.0.4. I get invalid xml 
> parsing errors on app startup. When I remove the taglib elements from 
> my web.xml file, the app has no startup problems. These tags
> work fine with
> 3.2.1. Is this caused by improper installation of the JSTL?
> 
> Error:
> 
> PARSE error at line 17 column 12
> 
> org.xml.sax.SAXParseException: The content of element type "servlet" 
> must match
> 
> "(icon?,servlet-name,display-name?,description?,(servlet-class
> |jsp-file)
> 
> ,init-pa
> 
> ram*,load-on-startup?,security-role-ref*)".
> 
> web.xml excerpt
> 
> 
> 
> 
> 
> /WEB-INF/struts-bean.tld
> 
> /WEB-INF/struts-bean.tld
> 
> 
> 
> 
> 
> /WEB-INF/struts-html.tld
> 
> /WEB-INF/struts-html.tld
> 
> 
> 
> 
> 
> /WEB-INF/struts-logic.tld
> 
> /WEB-INF/struts-logic.tld
> 
> 
> 
> 
> 
> /WEB-INF/struts-template.tld
> 
> /WEB-INF/struts-template.tld
> 
> 
> 
> 
> 
> /WEB-INF/dbtags.tld
> 
> /WEB-INF/dbtags.tld
> 
> 
> 
> 
> 
> Any ideas?
> 
> Rob Swan
> Director of Operations
> Object Publishing Software
> Phone:  206-545-6851 ext 128
> Email: [EMAIL PROTECTED]
>  
> 

--
To unsubscribe, e-mail:

For additional commands, e-mail:




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




request.getContextPath()

2002-10-18 Thread Chen, Gin
Why is this not returning the same thing as the scriplet version?


<%= request.getContextPath() %>

Thanks,
-Tim

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




RE: request.getContextPath()

2002-10-18 Thread Shawn Bayern
On Fri, 18 Oct 2002, Karr, David wrote:

> This seems confusing, but I think the specification is reasonably
> clear on this.  I believe you need
> "${pageContext.request.contextPath}" instead.

Right.  There isn't any implicit 'request' object.  It's named
'requestScope' to emphasize that it's used to retrieve scoped attributes.
When you want to refer to the current page's HttpServletRequest instance
itself, you need to do so through ${pageContext}.

Shawn


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




RE: request.getContextPath()

2002-10-18 Thread Karr, David
This seems confusing, but I think the specification is reasonably clear on
this.  I believe you need "${pageContext.request.contextPath}" instead.

> -Original Message-
> From: Chen, Gin [mailto:Gin_Chen@;tvratings.com]
> Sent: Friday, October 18, 2002 2:48 PM
> To: 'Tag Libraries Users List'
> Subject: request.getContextPath()
> 
> 
> Why is this not returning the same thing as the scriplet version?
> 
> 
> <%= request.getContextPath() %>
> 
> Thanks,
> -Tim
> 
> --
> To unsubscribe, e-mail:   
> 
> For additional commands, e-mail: 
> 
> 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




Help with JSTL and Tomcat 4.0.4 - Tomcat Sax Parser Error in Reading web.xml

2002-10-18 Thread Rob Swan
I am trying to convert from Tomcat 3.2.1 to 4.0.4. I get invalid xml
parsing errors on app startup. When I remove the taglib elements from my
web.xml file, the app has no startup problems. These tags work fine with
3.2.1. Is this caused by improper installation of the JSTL?

Error:

PARSE error at line 17 column 12

org.xml.sax.SAXParseException: The content of element type "servlet"
must match

"(icon?,servlet-name,display-name?,description?,(servlet-class|jsp-file)

,init-pa

ram*,load-on-startup?,security-role-ref*)".

web.xml excerpt





/WEB-INF/struts-bean.tld

/WEB-INF/struts-bean.tld





/WEB-INF/struts-html.tld

/WEB-INF/struts-html.tld





/WEB-INF/struts-logic.tld

/WEB-INF/struts-logic.tld





/WEB-INF/struts-template.tld

/WEB-INF/struts-template.tld





/WEB-INF/dbtags.tld

/WEB-INF/dbtags.tld





Any ideas?

Rob Swan
Director of Operations
Object Publishing Software
Phone:  206-545-6851 ext 128
Email: [EMAIL PROTECTED]
 



RE: JSTL on the fly

2002-10-18 Thread Chen, Gin
Thanks Hans! :)
I was just trying to be lazy and do the creation of the bean in the fmt tag.
:-P
-Tim

-Original Message-
From: Hans Bergsten [mailto:hans@;gefionsoftware.com]
Sent: Friday, October 18, 2002 1:44 PM
To: Tag Libraries Users List
Subject: Re: JSTL on the fly


Chen, Gin wrote:
> Does JSTL EL support creating objects?
> 
> for example the following sniplet:
> 
> <%= new java.util.Date() %>
> 
> can i do this using jstl tags without first having to set up a bean?
> 
> in particular. I want to use the fmt tag to format this date.

No, but you can use the standard  action to create an
instance of java.util.Date:

   
   

Don't be scared by the "bean" term; a bean is just a class with a
no-argument constructor (all that's needed for ) and
methods using the get/setPropertyName() naming convention (needed
to access properties with EL expressions or ).

Hans
-- 
Hans Bergsten   [EMAIL PROTECTED]
Gefion Software http://www.gefionsoftware.com
JavaServer Pageshttp://TheJSPBook.com


--
To unsubscribe, e-mail:

For additional commands, e-mail:


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




Re: JSTL on the fly

2002-10-18 Thread Hans Bergsten
Chen, Gin wrote:

Does JSTL EL support creating objects?

for example the following sniplet:

<%= new java.util.Date() %>

can i do this using jstl tags without first having to set up a bean?

in particular. I want to use the fmt tag to format this date.


No, but you can use the standard  action to create an
instance of java.util.Date:

  
  

Don't be scared by the "bean" term; a bean is just a class with a
no-argument constructor (all that's needed for ) and
methods using the get/setPropertyName() naming convention (needed
to access properties with EL expressions or ).

Hans
--
Hans Bergsten		[EMAIL PROTECTED]
Gefion Software		http://www.gefionsoftware.com
JavaServer Pages	http://TheJSPBook.com


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




JSTL on the fly

2002-10-18 Thread Chen, Gin
Does JSTL EL support creating objects?

for example the following sniplet:

<%= new java.util.Date() %>

can i do this using jstl tags without first having to set up a bean?

in particular. I want to use the fmt tag to format this date.

Thanks,
-Tim

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




Re: Does JSTL XML taglibs ignore XMLNamespace of input document?

2002-10-18 Thread Shawn Bayern
On Fri, 18 Oct 2002 [EMAIL PROTECTED] wrote:

> This long line could be shorten by the way I suggested as follows :
> 
> -
> http://schemas.xmlsoap.org/soap/envelope"/>
> http://baseball.azb.co.jp/Apache/DataStore/"/>
>  ="${ns}"/>
> -

Indeed, this is one thing the standard could add in the future.  It could
also use a more specific syntax, along the lines of

 

-- 
Shawn Bayern
"JSTL in Action"   http://www.jstlbook.com


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




Re: Does JSTL XML taglibs ignore XMLNamespace of input document?

2002-10-18 Thread Shawn Bayern
On Fri, 18 Oct 2002 [EMAIL PROTECTED] wrote:

> This one line of code is too long! Don't you think so? 

Yes.

> How can I make this shorter?

You can't. :)  At least, I can't think of any straightforward, general
ways to simplify that code.

It's possible that a future version of JSTL might let you declare a
namespace and keep the prefix->namespace mapping in effect throughout your
use of the  tags.  Without that, there's not much you can do.  Note
that in many cases, you can probably get away with simply using name() in
and ignoring the namespace; often, you already know what namespace to
expect, and you can confirm it beforehand with a schema or other
validation.

-- 
Shawn Bayern
"JSTL in Action"   http://www.jstlbook.com


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




Re: Does JSTL XML taglibs ignore XMLNamespace of input document?

2002-10-18 Thread matsuhashi

additive:

-
http://schemas.xmlsoap.org/soap/envelope']/Body[namespace-uri()
='http://schemas.xmlsoap.org/soap/envelope']/getPitchingResult[namespace-uri

)='http://baseball.azb.co.jp/Apache/DataStore/']/name[namespace-uri()
='http://baseball.azb.co.jp/Apache/DataStore/']"/>
-

This long line could be shorten by the way I suggested as follows :

-
http://schemas.xmlsoap.org/soap/envelope"/>
http://baseball.azb.co.jp/Apache/DataStore/"/>

-


 Kazuaki Matsuhashi
 QUICK Corp,
 Japan





--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




Re: Does JSTL XML taglibs ignore XMLNamespace of input document?

2002-10-18 Thread matsuhashi

Shawn Bayern wrote :
> In XPath, "n:a" is not a valid step; it
> does not refer, as you seem to be expecting, to the node named 'a' in the
> namespace identified by prefix 'n'.  If you want to refer to this node,
> you'll probably want to use the name() and namespace-uri() functions in
> XPath.

Yes, I fully understand what you say, but ... what I want is "shortness of
the JSP code".

Consider the following example XML: a fairy long string of NamespaceURIs
-
http://schemas.xmlsoap.org/soap/envelope/";
  SOAP-ENV:encodingStyle
="http://schemas.xmlsoap.org/soap/encoding/";>
 
http://baseball.azb.co.jp/Apache/";
   SOAP-ENV:mustUnderstand="1">
 5
   
 
 
http://baseball.azb.co.jp/Apache/DataStore/";>
   Akinobu Yoshida
   00

  

-

Then if I want to obtain the string value of  element, the JSP with
legal XPath would look like (I think)
-
http://schemas.xmlsoap.org/soap/envelope']/Body[namespace-uri()
='http://schemas.xmlsoap.org/soap/envelope']/getPitchingResult[namespace-uri

)='http://baseball.azb.co.jp/Apache/DataStore/']/name[namespace-uri()
='http://baseball.azb.co.jp/Apache/DataStore/']"/>
-

This one line of code is too long! Don't you think so? How can I make this
shorter?

I believe that one of the greate benefits of the custom-tag technology is
that it makes the JSP code shorter, easy to read.

The way I suggested may not be seen orthodx. It is really a way of
convenience. However I would like to point out why "Namespaces in XML"
specification introduced "namespace prefix" itself? Isn't it a way of
convenience to make XML documents withNamespaces shorter, easy to read?

> See the XPath standard or chapter 8 of "JSTL in Action."
Yes, definitely. I ordered it to amazon.com and waiting for


I appreciate your comment very much.

 Kazuaki Matsuhashi
 QUICK Corp,
 Japan




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




Re: might have found a bug in jslt 1.0.2

2002-10-18 Thread peter lin

I'm glad your just as confused as I am, since I honestly don't know
either :)

I was hoping you'd have the magic answer, but looks like I'll have to
dig around this weekend to figure what the exact cause is.  thanks for
responding to my obtuse questions, since I'm confused as to why this
behavior happens at all.  I'll post what ever I find, hopefully detailed
information about how to reproduce or track it down.

peter

Shawn Bayern wrote:
> 
> On Fri, 18 Oct 2002, peter lin wrote:
> 
> > it's only when the syntax is incorrect that it doesn't throw an
> > exception like "symbol cannot be resolved", "clascastexception" or
> > some other exception.  Right or wrong, I expect the EL to realize
> > "duh, that's the wrong syntax silly pete. I'm throwing an exception."
> 
> Which EL expression causes this?  If the syntax of an expression isn't
> parseable, the EL should throw an exception.  If the property is simply
> unknown, the behavior can depend on whether we're dealing with a Map or
> JavaBean; it's all defined by the spec.
> 
> Since our JSTL implementation doesn't directly produce logs, I'm just
> trying to figure out *exactly* what you're doing that does produce logs,
> and then trace it back to the code that ultimately causes them to be
> created.  Ideally, you'd have a minimal pair of two *identical* fragments,
> one of which uses the EL and produces the erroneous logs, and one of which
> doesn't.
> 
> Sorry if I'm being obtuse; I'm just not understanding the problem reports,
> or I'm missing some information.
> 
> Shawn
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




Re: might have found a bug in jslt 1.0.2

2002-10-18 Thread Shawn Bayern
On Fri, 18 Oct 2002, peter lin wrote:

> it's only when the syntax is incorrect that it doesn't throw an
> exception like "symbol cannot be resolved", "clascastexception" or
> some other exception.  Right or wrong, I expect the EL to realize
> "duh, that's the wrong syntax silly pete. I'm throwing an exception."

Which EL expression causes this?  If the syntax of an expression isn't
parseable, the EL should throw an exception.  If the property is simply
unknown, the behavior can depend on whether we're dealing with a Map or
JavaBean; it's all defined by the spec.

Since our JSTL implementation doesn't directly produce logs, I'm just
trying to figure out *exactly* what you're doing that does produce logs,
and then trace it back to the code that ultimately causes them to be
created.  Ideally, you'd have a minimal pair of two *identical* fragments,
one of which uses the EL and produces the erroneous logs, and one of which
doesn't.

Sorry if I'm being obtuse; I'm just not understanding the problem reports,
or I'm missing some information.

Shawn


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




Re: Does JSTL XML taglibs ignore XMLNamespace of input document?

2002-10-18 Thread Shawn Bayern
On Fri, 18 Oct 2002 [EMAIL PROTECTED] wrote:

> I have worked out about this issue and I believe I have got an idea of
> betterment to the jakarta standard taglibs1.0.x and possibly to the JSTL
> specification.
> 
> Here I refrain the initial issue I raised just to remind it. I coded the
> following JSP page

Sorry, I saw this the first time around, but it slipped through my mailbox
because I was away at a conference.

The issue isn't JSTL's, at least not directly.  You're just not using
XPath correctly.  Consider your example:

> -
> <%@ taglib uri="/WEB-INF/x.tld" prefix="x" %>
> boon
>  ="someNamespace">baan
> $NoNS/a/b=
> $WithNS/a/b=
> $WithNS/n:a/n:b=

Here, both documents are parsed correctly and available for your use.  
However, the XPath expressions that you're using against the document that
uses namespaces are incorrect.  In XPath, "n:a" is not a valid step; it
does not refer, as you seem to be expecting, to the node named 'a' in the
namespace identified by prefix 'n'.  If you want to refer to this node,
you'll probably want to use the name() and namespace-uri() functions in
XPath.  See the XPath standard or chapter 8 of "JSTL in Action."

-- 
Shawn Bayern
"JSTL in Action"   http://www.jstlbook.com


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




Re: might have found a bug in jslt 1.0.2

2002-10-18 Thread peter lin

without EL it works fine.  I've tried with scriplet code and it works
fine. I've tried it with the correct syntax and it works fine.

it's only when the syntax is incorrect that it doesn't throw an
exception like "symbol cannot be resolved", "clascastexception" or some
other exception.  Right or wrong, I expect the EL to realize "duh,
that's the wrong syntax silly pete. I'm throwing an exception."


when I have time, I'll try to verify jstl 1.0.2 with 4.0.6 and see if
has the same effect. If it doesn't cause continuous logging, it's
probably a bug in tomcat. The funny thing is the page compiles just
fine.

peter


Shawn Bayern wrote:
> 
> On Fri, 18 Oct 2002, peter lin wrote:
> 
> > It causes tomcat 4.1.12 to generate logs continuously. If I don't hit
> > stop in the browser, it will continue to generate logs. After a couple
> > of minutes, the log is tens of megs.
> >
> > I don't know if it's the responsibility of the EL to throw an
> > exception or if jasper should be responsible. with is why the subject
> > says maybe :)
> >
> > if you think it's a jasper bug, I will consult tomcat-dev and
> > investigate further. thanks.
> 
> Again, I'm not sure of the specific action that you're saying causes this
> looping.  Is there something in the EL that you're saying causes a loop?
> Is it the iteration over 'cookie'?  Can you replicate it without using the
> EL?
> 
> Shawn
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




Re: might have found a bug in jslt 1.0.2

2002-10-18 Thread Shawn Bayern
On Fri, 18 Oct 2002, peter lin wrote:

> It causes tomcat 4.1.12 to generate logs continuously. If I don't hit
> stop in the browser, it will continue to generate logs. After a couple
> of minutes, the log is tens of megs.
> 
> I don't know if it's the responsibility of the EL to throw an
> exception or if jasper should be responsible. with is why the subject
> says maybe :)
> 
> if you think it's a jasper bug, I will consult tomcat-dev and
> investigate further. thanks.

Again, I'm not sure of the specific action that you're saying causes this
looping.  Is there something in the EL that you're saying causes a loop?  
Is it the iteration over 'cookie'?  Can you replicate it without using the
EL?

Shawn


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




Re: Does JSTL XML taglibs ignore XMLNamespace of input document?

2002-10-18 Thread matsuhashi

I have worked out about this issue and I believe I have got an idea of
betterment to the jakarta standard taglibs1.0.x and possibly to the JSTL
specification.

Here I refrain the initial issue I raised just to remind it. I coded the
following JSP page
-
<%@ taglib uri="/WEB-INF/x.tld" prefix="x" %>
boon
baan
$NoNS/a/b=
$WithNS/a/b=
$WithNS/n:a/n:b=
-
The only difference between $NoNS object and $WithNS object is XML
Namespace usage. I got the following response from the application.
-
$NoNS/a/b=boon
$WithNS/a/b=
$WithNS/n:a/n:b=
-
I could not get "baan" output.

I looked at the taglibs1.0.2 source code and studied Jaxen. Then I did an
experiment (source code change) locally on my PC. I modifed the source code
of "org.apache.taglibs.standard.tag.common.xml.XPathUtil" class slightly as
follows:
-
/**
 * Returns a String given an XPath expression and a single context
 * Node.
 */
public String valueOf(Node n, String xpath) throws SAXPathException {
 staticInit();
XPath xp = new DOMXPath(xpath);

//--- modification by MATSUHASHI,kazuaki--
start
//
//  lookup a Map which should contain pairs of XML Namespace prefix
//  and URI to be used within XPath expression, then put them into
//  SimpleNamespaceContext object which will be refered by jaxen
engine
//
//  just insert the following statements, that's all
Map nsCollection
= (Map)pageContext.getAttribute("inputDocumentXmlNamespaces");
if (nsCollection != null) {
Set prefixes = nsCollection.keySet();
Iterator nsIterator = prefixes.iterator();
while (nsIterator.hasNext()) {
String prefix = (String)nsIterator.next();
String nsuri  = (String)nsCollection.get(prefix);
System.out.println("prefix=" + prefix);
System.out.println("NSURI =" + nsuri);
nc.addNamespace(prefix, nsuri);
}
}
//--- modification by MATSUHASHI,kazuaki--- end

// return xp.valueOf(getLocalContext(n));
return xp.stringValueOf(getLocalContext(n));
}
-



The JSP to test the new class is as follows
-
<%@ taglib uri="/WEB-INF/x.tld" prefix="x" %>


An experimental modification of JSTL XPath
to enable access XML with SOME Namespaces
case1 : input XML using NO Namespace --- possible to obtain "boon" by
jakarta-taglibs standard-1.0.2
boon

XMLboon
XPath$NoNS/a/b
value





case2 :input XML using some Namespaces --- impossible to obtain "baan"
by standard-1.0.2, but enabled by code modification
baan
<%@ page import="java.util.HashMap" %>
<% HashMap ns = new HashMap();
   ns.put("p", "someNamespaceURI");
   pageContext.setAttribute("inputDocumentXmlNamespaces", ns);
%>

XML
baan
XPath$WithNS/p:a/p:b
value





-


Then I could get the following display:
-
An experimental modification of JSTL XPath
to enable access XML with SOME Namespaces

case1 : input XML using NO Namespace --- possible to obtain "boon" by
jakarta-taglibs standard-1.0.2
XML  boon
XPath $NoNS/a/b
value boon

case2 :input XML using some Namespaces --- impossible to obtain "baan" by
standard-1.0.2, enabled by code modification
XML  baan
XPath $WithNS/p:a/p:b
value baan
-

The code modification above is meant to inform Jaxen about the Namespace
prefixes and URIs to be used within the XPath expression. The URI string is
significant which should match with the URI string used in the input XML
document, but the prefix is not really significant --- the prefix
characters in the XPath does not have to be the same as the prefix
characters used in the XML.

The modification was enough to deal with (though just to print the text()
of the selected Node) a pretty complexed XML with multiple Namespaces (such
as SOAP Envelope containing a XHTML document); thanks for Jaxen's fullness.

I belive that this experiment proved that a small code change can enable
the standard-1.0.x to deal with input XML documents with XML namespaces
with fully-Namespace aware XPath expressions.




I have two other points to mention.

(1)  rather than JSP scriptlet, but did not work

I also tried the following JSP: I meant to use  to create an
a

Re: might have found a bug in jslt 1.0.2

2002-10-18 Thread peter lin

It causes tomcat 4.1.12 to generate logs continuously. If I don't hit
stop in the browser, it will continue to generate logs. After a couple
of minutes, the log is tens of megs.

I don't know if it's the responsibility of the EL to throw an exception
or if jasper should be responsible. with is why the subject says maybe
:)

if you think it's a jasper bug, I will consult tomcat-dev and
investigate further. thanks.

peter

Shawn Bayern wrote:
> 
> On Thu, 17 Oct 2002, peter lin wrote:
> 
> > It looks like using  won't retrieve
> > the value, since acookie is a hashentry, it can't do
> > acookie.getName().toString().  I'm guessing that is correct
> > functionality right?
> 
> Right, for ${cookie} is a Map of all cookie names to Cookie instances.
> 
> So, in the context of the test page, where does the bug come up?
> 
> --
> Shawn Bayern
> "JSTL in Action"   http://www.jstlbook.com
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




Re: print out the items of a collection in reverse order

2002-10-18 Thread Shawn Bayern
On Fri, 18 Oct 2002, Hao Ding wrote:

> Is there a way to print out the items of a collection (e.x an array)
> in reverse order using  or some other JSTL core tags?

Not as such.  But since you ask, one solution does occur to me:

You can loop through the collection with  the first time and
add elements to a SortedMap with a key derived from the negation of the
current 'count', then loop through this new SortedMap.  (To do this
properly, you'd need first to determine the collection's size.  Then,
you'd need to produce each new key with  based in part
on this size, for keys set by  are
always textual, and numerical keys won't, by default, sort lexically the
way you want them to.  To put it another way, you need to pad the numbers
with zeroes by using 'minIntegerDigits'.)

Thus, one solution that prints out the elements of an array or List named
'original' in reverse order could look like this:

 
 
  
 
 
  
  
 
 
  
 

However, I think we're long past the point where it's easier to do this in
a servlet or some other backing Java code.  :-)

-- 
Shawn Bayern
"JSTL in Action"   http://www.jstlbook.com


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




Re: might have found a bug in jslt 1.0.2

2002-10-18 Thread Shawn Bayern
On Thu, 17 Oct 2002, peter lin wrote:

> It looks like using  won't retrieve
> the value, since acookie is a hashentry, it can't do
> acookie.getName().toString().  I'm guessing that is correct
> functionality right?

Right, for ${cookie} is a Map of all cookie names to Cookie instances.

So, in the context of the test page, where does the bug come up?

-- 
Shawn Bayern
"JSTL in Action"   http://www.jstlbook.com


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




Re: might have found a bug in jslt 1.0.2

2002-10-18 Thread peter lin


I wrote a basic test page and this is the result I get.

output

print out the classname

java.util.HashMap$Entry 
java.util.HashMap$Entry 
java.util.HashMap$Entry 

print out the cookie

id1=value_for_id1
JSESSIONID=1B6A8CE1F51A31E335719420A239BEB2
id2=value_for_id2


The source is below:
-
<%@ taglib prefix="c" uri="http://java.sun.com/jstl/core"; %>

print out the classname

<%
  Object ck = pageContext.getAttribute("acookie");
  out.println(ck.getClass().getName());
%>


print out the cookie

=

-

It looks like using  won't retrieve the
value, since acookie is a hashentry, it can't do
acookie.getName().toString().  I'm guessing that is correct
functionality right?

peter

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




print out the items of a collection in reverse order

2002-10-18 Thread Hao Ding
Hi all,

Is there a way to print out the items of a collection (e.x an array) in 
reverse order using  or some other JSTL core tags?

Thanks
Hao


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 



Re: might have found a bug in jslt 1.0.2

2002-10-18 Thread peter lin

we did verify "acookie" exists. I should have been more clear in my
original email.

shouldn't JSTL throw an exception, since "acookie" is wrapped, so using
 is the correct syntax. Using
 should throw an exception, rather than
go into an infinite loop and generate megs of error logs?


peter




Shawn Bayern wrote:
> 
> On Thu, 17 Oct 2002, peter lin wrote:
> 
> > But if I use this syntax, it causes tomcat to generate a ton of logs.
> >
> > 
> 
> To determine whether this is a bug in JSTL or in Tomcat, try replacing
> this tag with a scriptlet that performs the equivalent operation --
> something like
> 
>   <%= ((Cookie) pageContext.getAttribute("acookie")).getValue() %>
> 
> Shawn
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




Re: might have found a bug in jslt 1.0.2

2002-10-18 Thread peter lin

I will dig deeper and post my findings.

thanks

peter

Shawn Bayern wrote:
> 
> On Thu, 17 Oct 2002, peter lin wrote:
> 
> > we did verify "acookie" exists. I should have been more clear in my
> > original email.
> 
> That's not really the issue; the question is what's causing the error
> logs that you're suggesting are indicative of a bug.  Since the Standard
> Taglib simply results 'acookie.value' into a call to getValue() of your
> Cookie, it seems unlikely that the problem lies with the Standard Taglib,
> unless I'm misunderstanding your report.
> 
> > shouldn't JSTL throw an exception, since "acookie" is wrapped, so
> > using  is the correct syntax.
> > Using  should throw an exception,
> > rather than go into an infinite loop and generate megs of error logs?
> 
> No, the tag should simply result in a call to
> acookie.getName().toString().  That's why I'm suggesting you throw
> correspondent code in a scriptlet and see if it fails in the same way.
> 
> --
> Shawn Bayern
> "JSTL in Action"   http://www.jstlbook.com
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




Re: might have found a bug in jslt 1.0.2

2002-10-18 Thread Shawn Bayern
On Thu, 17 Oct 2002, peter lin wrote:

> we did verify "acookie" exists. I should have been more clear in my
> original email.

That's not really the issue; the question is what's causing the error
logs that you're suggesting are indicative of a bug.  Since the Standard
Taglib simply results 'acookie.value' into a call to getValue() of your
Cookie, it seems unlikely that the problem lies with the Standard Taglib,
unless I'm misunderstanding your report.

> shouldn't JSTL throw an exception, since "acookie" is wrapped, so
> using  is the correct syntax.
> Using  should throw an exception,
> rather than go into an infinite loop and generate megs of error logs?

No, the tag should simply result in a call to
acookie.getName().toString().  That's why I'm suggesting you throw
correspondent code in a scriptlet and see if it fails in the same way.

-- 
Shawn Bayern
"JSTL in Action"   http://www.jstlbook.com


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




Re: might have found a bug in jslt 1.0.2

2002-10-18 Thread Shawn Bayern
On Thu, 17 Oct 2002, peter lin wrote:

> But if I use this syntax, it causes tomcat to generate a ton of logs.
> 
> 

To determine whether this is a bug in JSTL or in Tomcat, try replacing
this tag with a scriptlet that performs the equivalent operation --
something like

  <%= ((Cookie) pageContext.getAttribute("acookie")).getValue() %>

Shawn


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




[ANN] Expresso 5.0 Released

2002-10-18 Thread Sandra Cann
Expresso 5.0 a major new release with more than 50 new features is now
available for download. Expresso is an open source architectural J2EE
framework comprising application development components which extends
Struts for developing database-driven web applications. Download freely
from: http://www.jcorporate.com/product/expresso.html > Download link  

Expresso Tags is a subcomponent of Expresso that builds on the Apache
Tag Library. Expresso Tags includes a tag library for Expresso as well
as a Extended Struts Tag Library as part of the integration with Struts.


For more information on Expresso Tag Library see:
http://www.jcorporate.com/econtent/Content.do?state=resource&resource=58
5







--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




might have found a bug in jslt 1.0.2

2002-10-18 Thread peter lin

A co-worker discovered strange behavior, which may be a bug. We're
trying to print out cookie values to the page for testing and noticed it
generates several megs of application errors.

if we use the following syntax with a forEach, to access cookie, it
works.



But if I use this syntax, it causes tomcat to generate a ton of logs.




peter

--
To unsubscribe, e-mail:   
For additional commands, e-mail: