[ANN] Expresso 5.0 Released
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=resourceresource=58 5 -- To unsubscribe, e-mail: mailto:taglibs-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:taglibs-user-help;jakarta.apache.org
Re: might have found a bug in jslt 1.0.2
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 c:out value=${acookie.value.name}/ is the correct syntax.
Using c:out value=${acookie.name}/ 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: mailto:taglibs-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:taglibs-user-help;jakarta.apache.org
Re: might have found a bug in jslt 1.0.2
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 c:out value=${acookie.value.name}/ is the correct syntax.
Using c:out value=${acookie.name}/ 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: mailto:taglibs-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:taglibs-user-help;jakarta.apache.org
--
To unsubscribe, e-mail: mailto:taglibs-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:taglibs-user-help;jakarta.apache.org
print out the items of a collection in reverse order
Hi all, Is there a way to print out the items of a collection (e.x an array) in reverse order using c:forEach or some other JSTL core tags? Thanks Hao -- To unsubscribe, e-mail: mailto:taglibs-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:taglibs-user-help;jakarta.apache.org
Re: might have found a bug in jslt 1.0.2
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 classnamep
c:forEach var=acookie items=${cookie}
%
Object ck = pageContext.getAttribute(acookie);
out.println(ck.getClass().getName());
%br
/c:forEach
p
print out the cookiep
c:forEach var=acookie items=${cookie}
c:out value=${acookie.value.name}/=c:out
value=${acookie.value.value}/br
/c:forEach
-
It looks like using c:out value=${acookie.name}/ 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: mailto:taglibs-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:taglibs-user-help;jakarta.apache.org
Re: might have found a bug in jslt 1.0.2
On Thu, 17 Oct 2002, peter lin wrote:
It looks like using c:out value=${acookie.name}/ 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: mailto:taglibs-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:taglibs-user-help;jakarta.apache.org
Re: print out the items of a collection in reverse order
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 c:forEach 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 c:forEach 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 fmt:formatNumber based in part
on this size, for keys set by c:set target=... property=... 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:
jsp:useBean id=reversed class=java.util.TreeMap /
c:forEach items=${original} var=item varStatus=s
c:set var=size value=${s.count} /
/c:forEach
c:forEach items=${foo} var=item varStatus=s
fmt:formatNumber value=${size-s.count}
minIntegerDigits=${size/10 + 1} var=n /
c:set target=${reversed} property=${n} value=${item} /
/c:forEach
c:forEach items=${reversed} var=item
c:out value=${item.value} /
/c:forEach
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: mailto:taglibs-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:taglibs-user-help;jakarta.apache.org
Re: might have found a bug in jslt 1.0.2
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 c:out value=${acookie.name}/ 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: mailto:taglibs-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:taglibs-user-help;jakarta.apache.org
--
To unsubscribe, e-mail: mailto:taglibs-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:taglibs-user-help;jakarta.apache.org
Re: Does JSTL XML taglibs ignore XMLNamespace of input document?
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 %
x:parse var=NoNSabboon/b/a/x:parse
x:parse var=WithNSn:a xmlns:n
=someNamespacen:bbaan/n:b/n:a/x:parse
$NoNS/a/b=x:out select=$NoNS/a/b/br
$WithNS/a/b=x:out select=$WithNS/a/b/br
$WithNS/n:a/n:b=x:out select=$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 %
html
body
h2An experimental modification of JSTL XPath/h2
h3to enable access XML with SOME Namespaces/h3
pcase1 : input XML using NO Namespace --- possible to obtain boon by
jakarta-taglibs standard-1.0.2/p
x:parse var=NoNSabboon/b/a/x:parse
table border=1
trtdXML/tdtdlt;alt;bboonlt;/blt;/a/td/tr
trtdXPath/tdtd$NoNS/a/b/td/tr
trtdvalue/td
tdx:out select=$NoNS/a/b//td/tr
/table
brbr
pcase2 :input XML using some Namespaces --- impossible to obtain baan
by standard-1.0.2, but enabled by code modification/p
x:parse var=WithNSn:a xmlns:n
=someNamespaceURIn:bbaan/n:b/n:a/x:parse
% page import=java.util.HashMap %
% HashMap ns = new HashMap();
ns.put(p, someNamespaceURI);
pageContext.setAttribute(inputDocumentXmlNamespaces, ns);
%
table border=1
trtdXML/tdtdlt;n:a xmlns:n=someNamespaceURI
lt;n:bbaanlt;/n:blt;/n:a/td/tr
trtdXPath/tdtd$WithNS/p:a/p:b/td/tr
trtdvalue/td
tdx:out select=$WithNS/p:a/p:b//td/tr
/table
/body
/html
-
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 abboon/b/a
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 n:a xmlns:n=someNamespaceURIn:bbaan/n:b/n:a
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()
Re: might have found a bug in jslt 1.0.2
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: mailto:taglibs-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:taglibs-user-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:taglibs-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:taglibs-user-help;jakarta.apache.org
Re: Does JSTL XML taglibs ignore XMLNamespace of input document?
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 % x:parse var=NoNSabboon/b/a/x:parse x:parse var=WithNSn:a xmlns:n =someNamespacen:bbaan/n:b/n:a/x:parse $NoNS/a/b=x:out select=$NoNS/a/b/br $WithNS/a/b=x:out select=$WithNS/a/b/br $WithNS/n:a/n:b=x:out select=$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: mailto:taglibs-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:taglibs-user-help;jakarta.apache.org
Re: might have found a bug in jslt 1.0.2
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: mailto:taglibs-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:taglibs-user-help;jakarta.apache.org
Re: might have found a bug in jslt 1.0.2
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: mailto:taglibs-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:taglibs-user-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:taglibs-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:taglibs-user-help;jakarta.apache.org
Re: Does JSTL XML taglibs ignore XMLNamespace of input document?
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 - SOAP-ENV:Envelope xmlns:SOAP-ENV =http://schemas.xmlsoap.org/soap/envelope/; SOAP-ENV:encodingStyle =http://schemas.xmlsoap.org/soap/encoding/; SOAP-ENV:Header t:Transaction xmlns:t=http://baseball.azb.co.jp/Apache/; SOAP-ENV:mustUnderstand=1 5 /t:Transaction /SOAP-ENV:Header SOAP-ENV:Body m:getPitchingResult xmlns:m =http://baseball.azb.co.jp/Apache/DataStore/; m:nameAkinobu Yoshida/m:name m:No00/m:No /m:getPitchingResult /SOAP-ENV:Body /SOAP-ENV:Envelope - Then if I want to obtain the string value of m:name element, the JSP with legal XPath would look like (I think) - x:out select=$foo/Envelope[namespace-uri() ='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: mailto:taglibs-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:taglibs-user-help;jakarta.apache.org
Re: Does JSTL XML taglibs ignore XMLNamespace of input document?
additive:
-
x:out select=$foo/Envelope[namespace-uri()
='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 :
-
c:set target=ns property=s value=
http://schemas.xmlsoap.org/soap/envelope/
c:set target=ns property=t value=
http://baseball.azb.co.jp/Apache/DataStore//
x:out select=$foo/s:Envelpe/s:Body/t:getPitchingResult/t:name namespaces
=${ns}/
-
Kazuaki Matsuhashi
QUICK Corp,
Japan
--
To unsubscribe, e-mail: mailto:taglibs-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:taglibs-user-help;jakarta.apache.org
Re: Does JSTL XML taglibs ignore XMLNamespace of input document?
On Fri, 18 Oct 2002 [EMAIL PROTECTED] wrote:
This long line could be shorten by the way I suggested as follows :
-
c:set target=ns property=s value=
http://schemas.xmlsoap.org/soap/envelope/
c:set target=ns property=t value=
http://baseball.azb.co.jp/Apache/DataStore//
x:out select=$foo/s:Envelpe/s:Body/t:getPitchingResult/t:name namespaces
=${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
x:registerNamespace prefix=... uri=... scope=... /
--
Shawn Bayern
JSTL in Action http://www.jstlbook.com
--
To unsubscribe, e-mail: mailto:taglibs-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:taglibs-user-help;jakarta.apache.org
JSTL on the fly
Does JSTL EL support creating objects? for example the following sniplet: center%= new java.util.Date() %/center 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: mailto:taglibs-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:taglibs-user-help;jakarta.apache.org
Re: JSTL on the fly
Chen, Gin wrote:
Does JSTL EL support creating objects?
for example the following sniplet:
center%= new java.util.Date() %/center
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 jsp:useBean action to create an
instance of java.util.Date:
jsp:useBean id=now class=java.util.Date /
fmt:formatDate value=${now} ... /
Don't be scared by the bean term; a bean is just a class with a
no-argument constructor (all that's needed for jsp:useBean) and
methods using the get/setPropertyName() naming convention (needed
to access properties with EL expressions or jsp:get/setProperty).
Hans
--
Hans Bergsten [EMAIL PROTECTED]
Gefion Software http://www.gefionsoftware.com
JavaServer Pages http://TheJSPBook.com
--
To unsubscribe, e-mail: mailto:taglibs-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:taglibs-user-help;jakarta.apache.org
RE: JSTL on the fly
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:
center%= new java.util.Date() %/center
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 jsp:useBean action to create an
instance of java.util.Date:
jsp:useBean id=now class=java.util.Date /
fmt:formatDate value=${now} ... /
Don't be scared by the bean term; a bean is just a class with a
no-argument constructor (all that's needed for jsp:useBean) and
methods using the get/setPropertyName() naming convention (needed
to access properties with EL expressions or jsp:get/setProperty).
Hans
--
Hans Bergsten [EMAIL PROTECTED]
Gefion Software http://www.gefionsoftware.com
JavaServer Pageshttp://TheJSPBook.com
--
To unsubscribe, e-mail:
mailto:taglibs-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail:
mailto:taglibs-user-help;jakarta.apache.org
--
To unsubscribe, e-mail: mailto:taglibs-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:taglibs-user-help;jakarta.apache.org
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 /servlet-mapping taglib taglib-uri/WEB-INF/struts-bean.tld/taglib-uri taglib-location/WEB-INF/struts-bean.tld/taglib-location /taglib taglib taglib-uri/WEB-INF/struts-html.tld/taglib-uri taglib-location/WEB-INF/struts-html.tld/taglib-location /taglib taglib taglib-uri/WEB-INF/struts-logic.tld/taglib-uri taglib-location/WEB-INF/struts-logic.tld/taglib-location /taglib taglib taglib-uri/WEB-INF/struts-template.tld/taglib-uri taglib-location/WEB-INF/struts-template.tld/taglib-location /taglib taglib taglib-uri/WEB-INF/dbtags.tld/taglib-uri taglib-location/WEB-INF/dbtags.tld/taglib-location /taglib /web-app Any ideas? Rob Swan Director of Operations Object Publishing Software Phone: 206-545-6851 ext 128 Email: [EMAIL PROTECTED]
RE: request.getContextPath()
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?
c:out value=${request.contextPath}/
%= request.getContextPath() %
Thanks,
-Tim
--
To unsubscribe, e-mail:
mailto:taglibs-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail:
mailto:taglibs-user-help;jakarta.apache.org
--
To unsubscribe, e-mail: mailto:taglibs-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:taglibs-user-help;jakarta.apache.org
request.getContextPath()
Why is this not returning the same thing as the scriplet version?
c:out value=${request.contextPath}/
%= request.getContextPath() %
Thanks,
-Tim
--
To unsubscribe, e-mail: mailto:taglibs-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:taglibs-user-help;jakarta.apache.org
RE: Help with JSTL and Tomcat 4.0.4 - Tomcat Sax Parser Error in Reading web.xml
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] mailto:robswan;objectpublish.com -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 /servlet-mapping taglib taglib-uri/WEB-INF/struts-bean.tld/taglib-uri taglib-location/WEB-INF/struts-bean.tld/taglib-location /taglib taglib taglib-uri/WEB-INF/struts-html.tld/taglib-uri taglib-location/WEB-INF/struts-html.tld/taglib-location /taglib taglib taglib-uri/WEB-INF/struts-logic.tld/taglib-uri taglib-location/WEB-INF/struts-logic.tld/taglib-location /taglib taglib taglib-uri/WEB-INF/struts-template.tld/taglib-uri taglib-location/WEB-INF/struts-template.tld/taglib-location /taglib taglib taglib-uri/WEB-INF/dbtags.tld/taglib-uri taglib-location/WEB-INF/dbtags.tld/taglib-location /taglib /web-app Any ideas? Rob Swan Director of Operations Object Publishing Software Phone: 206-545-6851 ext 128 Email: [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:taglibs-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:taglibs-user-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:taglibs-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:taglibs-user-help;jakarta.apache.org
RE: request.getContextPath()
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: mailto:taglibs-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:taglibs-user-help;jakarta.apache.org
RE: JSTL for Maps?
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.
input type=text name=junk readonly=readonly size=50
value=bean:write name=staffMember//
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: mailto:taglibs-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:taglibs-user-help;jakarta.apache.org
RE: JSTL for Maps?
-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: mailto:taglibs-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:taglibs-user-help;jakarta.apache.org
