[ANNOUNCE] JSP 2.1 and Faces 1.2 Public Review
We are pleased to announce the availability of the Public Review of the next versions of the specification for JavaServer Pages (JSP) and JavaServer Faces (Faces). JSP 2.1 is developed under JSR-245 and Faces 1.2 is developed under JSR-252. The two expert groups are working ogether to improve the alignment between these two powerful web presentation technologies. Building on the work that was accomplished with the Early Draft Review, this Public Review covers two additional areas that required better integration between JSP and Faces: - Tree Creation and Content Interweaving - Deferred expressions nested within iteration tags Please see Appendix E of the JSP spec and the Preface of the Faces spec to see details of what's changed. To access the specifications: JSP 2.1 PR (JSR-245) http://jcp.org/aboutJava/communityprocess/pr/jsr245/ Faces 1.2 PR (JSR-252) http://jcp.org/aboutJava/communityprocess/pr/jsr252/ Sincerely, The JSR-245 and JSR-252 Expert Groups - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSTL 1.0 URI vs. JSTL 1.1 URI
Jason,
Make sure your deployment descriptor (web.xml) is servlet 2.4 based,
as follows:
?xml version=1.0 encoding=ISO-8859-1?
web-app xmlns=http://java.sun.com/xml/ns/j2ee;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://java.sun.com/xml/ns/j2ee
http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd;
version=2.4
!-- web-app specific content --
/web-app
For an explanation of why this should solve your problem, please
see Appendix A of the JSTL spec (Compatibility and Migration).
-- Pierre
Jason Pincin wrote:
Greetings,
I'm fairly new to JSP and the java paradigm in general, and am trying to get
my feet wet with some simple pages. I'm starting with tomcat-5.0.27 and
jakarta-taglibs-standard-1.1.2. I've followed the documentation at
http://jakarta.apache.org/tomcat/tomcat-5.0-doc/appdev/processes.html on
putting together an initial application tree, I've put one page (index.jsp)
in ./web, I've put together build.xml, web.xml, and I've placed standard.jar
and jstl.jar from the taglibs package in my WEB-INF/lib dir.
I'm pretty certain I've got the basic structure down, but could be wrong.
The problem I'm having is this:
From what I've read, Tomcat 5.x utilizes JSP 2.0 JSTL 1.1. It's my
understanding that with JSTL 1.1, the taglib uri for JSTL Core change from
http://java.sun.com/jstl/core to http://java.sun.com/jsp/jstl/core.
Here is my index.jsp:
%@ page contentType=text/html %
%@ taglib uri=http://java.sun.com/jsp/jstl/core; prefix=c %
html
head
titleFirst JSP Page Ever/title
/head
body style=background-color: white; color: black;
c:set var=test value=hello /
Following number uSHOULD/u be six:
c:out value=${1 + 2 + 3} /
br/
Following uSHOULD/u be 'hello':
c:out value=${test} /
/body
/html
I don't think you can get much simpler. However, with that page as it is,
the out put looks like this:
Following number SHOULD be six: ${1 + 2 + 3}
Following SHOULD be 'hello': ${test}
Now... If I change the taglib uri from http://java.sun.com/jsp/jstl/core to
http://java.sun.com/jstl/core, the output looks like this:
Following number SHOULD be six: 6
Following SHOULD be 'hello': hello
This has me perplexed. Was wondering if anyone out there could shed some
light on this behavior for me? Thanks in advance for your time and
thoughts.
Jason Pincin
-
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: Problems with JSTL stuff
This alias is for comments on the JSTL specification. For support or usage questions, please use JSTL related lists such as [EMAIL PROTECTED]. Nath, Vikram wrote: Hello Folks, I am facing problems with the JSTL stuff. As soon as i include the following script to import JSTL I get error both shown below. I wish to know what I could do to rectify it. I badly need your advice and urgently, as it has held up my major stuff. I have used it before with a different server was5.1 but did not face problem. Right now I am using TomCat 5 is what i am using. pls advise %@ taglib prefix=c uri=http://java.sun.com/jsp/jstl/core; % the error is org.apache.jasper.JasperException: h3Validation error messages from TagLibraryValidator for c/h3pnull: java.lang.IllegalStateException: can't declare any more prefixes in this context/p org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler. java:94) org.apache.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java:404 ) org.apache.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java:112 ) org.apache.jasper.compiler.Validator.validateXmlView(Validator.java:1578) org.apache.jasper.compiler.Validator.validate(Validator.java:1524) org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:247) org.apache.jasper.compiler.Compiler.compile(Compiler.java:456) org.apache.jasper.compiler.Compiler.compile(Compiler.java:439) org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:5 53) org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:2 91) org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:301) org.apache.jasper.servlet.JspServlet.service(JspServlet.java:248) javax.servlet.http.HttpServlet.service(HttpServlet.java:856) org.apache.struts.action.RequestProcessor.doForward(RequestProcessor.java:10 69) org.apache.struts.tiles.TilesRequestProcessor.doForward(TilesRequestProcesso r.java:274) org.apache.struts.action.RequestProcessor.processForwardConfig(RequestProces sor.java:455) org.apache.struts.tiles.TilesRequestProcessor.processForwardConfig(TilesRequ estProcessor.java:320) org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:279) org.apache.struts.action.ActionServlet.process(ActionServlet.java:1482) org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:525) javax.servlet.http.HttpServlet.service(HttpServlet.java:763) javax.servlet.http.HttpServlet.service(HttpServlet.java:856) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using HTML tags inside scoped variable
Lukasz,
Simply use:
c:out value=${ErrorMessage} escapeXml=false/
-- Pierre
[EMAIL PROTECTED] wrote:
Hello,
Is it possible to keep a string with HTML tags inside a scoped variable.
I am trying to do something like:
c:set var=ErrorMessage scope=page
Message text... bc:out value=${Customer}//b
/c:set
Unfortunately when I try to insert the ErrorMessage into the page body
using:
c:out value=${ErrorMessage}/
I get something like:
Message text... bCustomer/b
Is it possible to make c:out not to escape HTML tags,
or maybe the whole approach is incorrect and there is other way to solve
it?
Thanks for help,
regards,
Lukasz
-
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: Adding attributes to an XML element in JSTL
Murray, OK, so I can settle (grudgingly) for writing/finding another XML tag library that can actually manipulate XML. The shame of it is that if I want to also use the JSTL tags (which I like very much) then I'll have to duplicate all of my XPath expressions and context variables for the new tags because the only JSTL tag that exposes a standard w3c.dom.Document is x:parse. If only x:set and x:forEach had a varDom attribute, then the JSTL could be easily complemented by other (naughty) XML-based tag libraries. When an XPath expression is evaluated, the result is mapped to a Java type according to the following rules: XPath Java - boolean - java.lang.Boolean number - java.lang.Number string - java.lang.String node-set - Type usable by JSTL XML-manipulation tags in the same JSTL implementation. The specific Java type representing node-sets may thus vary by implementation. If I understand you correctly, given that the only mapping that's not specified is 'node-set', you'd want the capability to force the mapping of an XPath node-set to be of a specific type, e.g. org.w3c.dom.NodeList. Correct? -- Pierre Murray Lang wrote: Are you saying that if I want to get user input (from a form) into XML for a back-end system then JSP is not suitable?. I can't accept that. I could use Struts (which seems like overkill), or write a tag library that took all of the form values and spat out w3c.dom.Document, but any changes to the input options would then require that a bean and its JAR be recompiled and re-deployed. Using a generic XML Tag library to put the values into an XML tree would be more maintainable. OK, so I can settle (grudgingly) for writing/finding another XML tag library that can actually manipulate XML. The shame of it is that if I want to also use the JSTL tags (which I like very much) then I'll have to duplicate all of my XPath expressions and context variables for the new tags because the only JSTL tag that exposes a standard w3c.dom.Document is x:parse. If only x:set and x:forEach had a varDom attribute, then the JSTL could be easily complemented by other (naughty) XML-based tag libraries. Murray At 04:24 PM 7/05/2004, you wrote: hey, come on, this is just a jsp - you would not really want to litter your presentation layer with all sorts of business-logic: if jstl goes down this path, it will end up being a crippled version of cfml or even worse asp... Murray Lang wrote: Actually, what the Sun JSTL web page says is: JSTL has support for common, structural tasks such as iteration and conditionals, tags for manipulating XML documents, internationalization tags, and SQL tags. manipulating! Anyway, I take your point that it is outside the scope of the JSTL XML tags at the moment. It seems to me a rather arbitrary limitation though. As the JSTL documentation says: ...when companies cooperate over the web, XML is the data format of choice for exchanging information.. IMHO being unable to manipulate XML is odd for a technology that has such language in it's documentation. An exchange of information involves two parties, one at least of which has created some XML. Thanks for the JXPath link. What worries me about it though is that it won't necessarily use the same DOM implementation as JSTL implementation, meaning that they won't work with each other. It seems a shame if this is the case. I'll look at it though - it might not be that bad. Cheers Murray At 01:33 AM 7/05/2004, you wrote: This is outside the scope of the taglibrary, JSTL xml taglibrary is for presentation of xml content, not for its manipulation. I recommend looking into a package such as JXPath to accomplish manipulation of the content of a DOM object. the nice thing is that JXPath can be scripted into a JSP, Servlet or Struts Action, which gives you the fredom to move it out of the Presentation layer (where you probibly shouldn't be placing such logic). http://jakarta.apache.org/commons/jxpath/ Good Luck -Mark Murray Lang wrote: Hi I've been using the XML tags in JSTL and found them very useful, however now I need to add an attribute to an XML element and have hit a brick wall. I've tried using c:set and EL, treating a DOM object as a bean, but the DOM interface is implementation-dependent and my implementation (xerces) doesn't lend itself to adding attributes with the simple EL view of bean properties. It seems to me that x:set needs to have a targetattribute along the same lines as c:set, but accepting an XPath expression. eg x:set select=12345 target=$myRoot//myElement[position()=0]/@myAttribute / where: - select can be either an XPath expression or an immediate value. - if @myAttribute doesn't currently exist in the element then it is created. Does this make sense? Is there a simple, portable, way of achieving this using JSTL as it stands? (Using c:set is not portable due to DOM being
Re: Adding attributes to an XML element in JSTL
Murray, Are you saying that if I want to get user input (from a form) into XML for a back-end system then JSP is not suitable?. I can't accept that. I could use Struts (which seems like overkill), or write a tag library that took all of the form values and spat out w3c.dom.Document, but any changes to the input options would then require that a bean and its JAR be recompiled and re-deployed. Using a generic XML Tag library to put the values into an XML tree would be more maintainable. I'm always interested in hearing more about XML-related use cases. If I understand you well, you want a JSP page (that is the target of a form submission) to create an XML document out of all the request parameters it receives. Correct? Where I don't follow is when you say that any changes to the input options would then require that a bean and its JAR be recompiled and re-deployed. Could you provide more specific details on your use-case? I'd like to dig a little more and see how best your use-case should be handled (given the constraints of your environment). This thread has already generated some great feedback from Mark and Kris, and I'm sure we can milk even more interesting comments from it... -- Pierre Murray Lang wrote: Are you saying that if I want to get user input (from a form) into XML for a back-end system then JSP is not suitable?. I can't accept that. I could use Struts (which seems like overkill), or write a tag library that took all of the form values and spat out w3c.dom.Document, but any changes to the input options would then require that a bean and its JAR be recompiled and re-deployed. Using a generic XML Tag library to put the values into an XML tree would be more maintainable. OK, so I can settle (grudgingly) for writing/finding another XML tag library that can actually manipulate XML. The shame of it is that if I want to also use the JSTL tags (which I like very much) then I'll have to duplicate all of my XPath expressions and context variables for the new tags because the only JSTL tag that exposes a standard w3c.dom.Document is x:parse. If only x:set and x:forEach had a varDom attribute, then the JSTL could be easily complemented by other (naughty) XML-based tag libraries. Murray At 04:24 PM 7/05/2004, you wrote: hey, come on, this is just a jsp - you would not really want to litter your presentation layer with all sorts of business-logic: if jstl goes down this path, it will end up being a crippled version of cfml or even worse asp... Murray Lang wrote: Actually, what the Sun JSTL web page says is: JSTL has support for common, structural tasks such as iteration and conditionals, tags for manipulating XML documents, internationalization tags, and SQL tags. manipulating! Anyway, I take your point that it is outside the scope of the JSTL XML tags at the moment. It seems to me a rather arbitrary limitation though. As the JSTL documentation says: ...when companies cooperate over the web, XML is the data format of choice for exchanging information.. IMHO being unable to manipulate XML is odd for a technology that has such language in it's documentation. An exchange of information involves two parties, one at least of which has created some XML. Thanks for the JXPath link. What worries me about it though is that it won't necessarily use the same DOM implementation as JSTL implementation, meaning that they won't work with each other. It seems a shame if this is the case. I'll look at it though - it might not be that bad. Cheers Murray At 01:33 AM 7/05/2004, you wrote: This is outside the scope of the taglibrary, JSTL xml taglibrary is for presentation of xml content, not for its manipulation. I recommend looking into a package such as JXPath to accomplish manipulation of the content of a DOM object. the nice thing is that JXPath can be scripted into a JSP, Servlet or Struts Action, which gives you the fredom to move it out of the Presentation layer (where you probibly shouldn't be placing such logic). http://jakarta.apache.org/commons/jxpath/ Good Luck -Mark Murray Lang wrote: Hi I've been using the XML tags in JSTL and found them very useful, however now I need to add an attribute to an XML element and have hit a brick wall. I've tried using c:set and EL, treating a DOM object as a bean, but the DOM interface is implementation-dependent and my implementation (xerces) doesn't lend itself to adding attributes with the simple EL view of bean properties. It seems to me that x:set needs to have a targetattribute along the same lines as c:set, but accepting an XPath expression. eg x:set select=12345 target=$myRoot//myElement[position()=0]/@myAttribute / where: - select can be either an XPath expression or an immediate value. - if @myAttribute doesn't currently exist in the element then it is created. Does this make sense? Is there a simple, portable, way of achieving this using JSTL as it stands? (Using c:set is not
Re: Standard-example
My question is: where is ${customers} decalerade or
got the values!!!
This is explained at the bottom of the home page for standard-examples:
Infrastructure
The source code for the JSTL examples includes class startup.Init to initilialize the objects used in the examples. This allows us to mimic the environment that would normally be used within an MVC architecture: the Controller invokes the business logic, saves the objects required by the web application into JSP scoped attributes (usually request), and then invokes the proper JSP page. For the sake of this examples webapp, all objects are saved in the application scope.
The application attributes are:
* customers
A collection of Customer objects
* intArray
An array of int's
* stringArray
An array of Strings
* numberMap
A Map instance associating Integer objects with their Spanish names
* enumeration
An enumeration on numberMap from above.
The classes of interest that hold the information manipulated by the JSP pages are:
* Customer
o int key
o String lastName
o String firstName
o Date birthDate
o Address address
* Address
o String line1
o String line2
o String city
o String state
o String country
khashayar sad wrote:
Hello!
I have installed the jslt-standard and look at the
examples.
I couldnt undrestand what happend with jslt-exaples:
for example you have this exapmle:
%@ taglib prefix=c
uri=http://java.sun.com/jsp/jstl/core; %
html
head
titleJSTL: Expression Language Support -- Expr
Example/title
/head
body bgcolor=#FF
h3c:out/h3
table border=1
c:forEach var=customer items=${customers}
tr
My question is: where is ${customers} decalerade or
got the values!!!
Any help?
Tanks
__
Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway
http://promotions.yahoo.com/design_giveaway/
-
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: Replacing returns with br
Not very intuitive, but the following should work:
c:set var=s5 value=First line\nSecond line/
c:out value=${fn:replace(s5,'\\\n','br')} escapeXml=false/
-- Pierre
Keith wrote:
I have a column in a database that is used to store a comments section. It's just a large
string (VARCHAR2(4000) in Oracle), and the information is entered into it via a
textarea form field. If I output that data to another textarea I can see that the
return characters are preserved in the database.
I was trying to output this column's data as normal text in HTML, but need to preserve
the returns somehow. I was thinking I could use the fn:replace action to turn them into
br's, but I'm not sure how it sees the return characters in the string. I tried this:
c:out value=${fn:replace(row.comments, '\n', 'br')} /
But get this error back:
org.apache.jasper.JasperException: /filename.jsp(281,2) ${fn:replace
(row.comments, '\n', 'br')} contains invalid expression(s):
javax.servlet.jsp.el.ELException: Encountered '\n, expected one of [INTEGER_LITERAL,
FLOATING_POINT_LITERAL, STRING_LITERAL, true, false, null, (, -
, not, !, empty, IDENTIFIER]
Anyone help with how I can go about doing this? Thanks!
Keith
-
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: ANN: JSTL Quick Reference
Bill, Great job! Thanks for the contribution. All feedback is most appreciated... The URIs you provide are the ones for JSTL 1.0. You may want to clarify that the URI is different depending on whether you use JSTL 1.0 or 1.1. [The URI specified for EL functions should only be the 1.1 flavor since functions were only introduced in JSTL 1.1]. Thanks again, -- Pierre [EMAIL PROTECTED] wrote: I noticed that there seems to be demand for a JSTL Quick Reference. When I was learning JSTL a couple of months ago I put together such a document and I thought others might find it of use. It can be downloaded from http://www.jadecove.com/jstl-quick-reference.pdf. The only downside about the document is that you have to make a book out of it yourself. I call this self-binding :) All feedback is most appreciated and if anyone would like to assist in publishing this document I will be glad to talk about it. Bill Siggelkow Jade Cove Solutions www.jadecove.com [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: JSTL 1.1 jaxp problem (under tomcat 5.0.19/java 1.4.2_03)
Yes, as Kris mentioned, please file a bug report with proper test cases. We'll have a look into it. -- Pierre Kris Schneider wrote: You're posting to the right place to make people aware of the problem. To formalize the issue, a bug report should probably get submitted: http://issues.apache.org/bugzilla/enter_bug.cgi?product=Taglibs As part of the report, it would be helpful to include a simplified test case (XML and JSP files) that reproduces the problem. If you have any questions about the bug submission process just let me (us) know. At this point, the problem seems to be either the way JSTL is using Xalan or Xalan itself. Quoting Johnson, Chris [EMAIL PROTECTED]: That gets rid of the xalan file search, but the performance is still awful. For now I guess I'll try to look into xslt, but this looks like a bug that needs to be fixed or something. Who else needs to know about this to get it either fixed, or to tell me what else I might be doing wrong (if anything). Here's more of what truss is spitting out if that helps: lwp_cond_wait(0x0002E7F8, 0x0002E7E0, 0xEC681B08) = 0 lwp_cond_signal(0x0002E7F8) = 0 lwp_mutex_lock(0x0002E7E0) = 0 lwp_mutex_unlock(0x0002E7E0)= 0 lwp_mutex_lock(0x0002E710) = 0 lwp_cond_wait(0x0002E728, 0x0002E710, 0x) = 0 lwp_cond_broadcast(0x0002E728) = 0 lwp_mutex_unlock(0x0002E778)= 0 lwp_mutex_lock(0x0002E778) = 0 lwp_cond_broadcast(0x0002E860) = 0 lwp_cond_wait(0x0002E860, 0x0002E848, 0x) = 0 lwp_mutex_unlock(0x0002E848)= 0 lwp_mutex_lock(0x0002E848) = 0 poll(0xE997FBC0, 0, 50) = 0 poll(0xE997FBC0, 0, 50) = 0 lwp_cond_wait(0x0002E7F8, 0x0002E7E0, 0xEC681B08) = 0 lwp_cond_signal(0x0002E7F8) = 0 lwp_cond_broadcast(0x0002E860) = 0 lwp_cond_wait(0x0002E860, 0x0002E848, 0x) = 0 poll(0xE997FBC0, 0, 50) = 0 poll(0xE997FBC0, 0, 50) = 0 poll(0xE997FBC0, 0, 50) = 0 lwp_cond_wait(0x0002E7F8, 0x0002E7E0, 0xEC681B08) = 0 lwp_cond_signal(0x0002E7F8) = 0 lwp_cond_broadcast(0x0002E860) = 0 lwp_cond_wait(0x0002E860, 0x0002E848, 0x) = 0 poll(0xE997FBC0, 0, 50) = 0 poll(0xE997FBC0, 0, 50) = 0 poll(0xE997FBC0, 0, 50) = 0 lwp_cond_wait(0x0002E7F8, 0x0002E7E0, 0xEC681B08) = 0 lwp_cond_signal(0x0002E7F8) = 0 lwp_cond_broadcast(0x0002E860) = 0 lwp_cond_wait(0x0002E860, 0x0002E848, 0x) = 0 lwp_mutex_unlock(0x0002E848)= 0 lwp_mutex_lock(0x0002E848) = 0 poll(0xE997FBC0, 0, 50) = 0 poll(0xE997FBC0, 0, 50) = 0 poll(0xE997FBC0, 0, 50) = 0 lwp_cond_wait(0x0002E7F8, 0x0002E7E0, 0xEC681B08) = 0 lwp_cond_signal(0x0002E7F8) = 0 lwp_mutex_lock(0x0002E7E0) = 0 lwp_mutex_unlock(0x0002E7E0)= 0 lwp_mutex_lock(0x0002E710) = 0 lwp_cond_wait(0x0002E728, 0x0002E710, 0x) = 0 lwp_cond_broadcast(0x0002E728) = 0 lwp_mutex_unlock(0x0002E778)= 0 lwp_mutex_lock(0x0002E778) = 0 lwp_mutex_lock(0x0002E848) = 0 lwp_cond_broadcast(0x0002E860) = 0 lwp_cond_wait(0x0002E860, 0x0002E848, 0x) = 0 poll(0xE997FBC0, 0, 50) = 0 poll(0xE997FBC0, 0, 50) = 0 poll(0xE997FBC0, 0, 50) = 0 It looks like a lot of locking, unlocking and waiting to me, but what do I know? Any help you can get me in escalating this would be much appreciated. Thanks again, Chris -Original Message- From: Kris Schneider [mailto:[EMAIL PROTECTED] Sent: Monday, March 15, 2004 3:37 PM To: Tag Libraries Users List Subject: RE: JSTL 1.1 jaxp problem (under tomcat 5.0.19/java 1.4.2_03) Try adding -Dorg.apache.xml.dtm.DTMManager=org.apache.xml.dtm.ref.DTMManagerDefault to JAVA_OPTS. Quoting Johnson, Chris [EMAIL PROTECTED]: Thanks, Kris. I did all that you suggested (setting the system properties and installing new jars), and indeed tomcat doesn't seem to be searching for the jaxp.properties file any longer. But, the performance is still just about as bad as before. So, I did truss again and now tomcat is looking for xalan.properties (stat64(/usr/j2sdk1.4.2_03/jre/lib/xalan.properties, 0xDF47F850) Err#2 ENOENT), just about as much, if not more, than it was for jaxp.properties. So how can I fix this? Chris -Original Message- From: Kris Schneider [mailto:[EMAIL PROTECTED] Sent: Monday, March 15, 2004 2:32 PM To: Tag Libraries Users
Re: maven repository
Taglibrary developers: This is an excellent example of how to take advantage of the new Apache Maven Repository. Taglibs Developers, how about publishing your taglibrary jars into the Maven Repository under /dist/java-repository. They'll get updated onto ibiblio.org/maven within 4 hours for Maven users to have accessibility to. Mark, Sounds like a great idea, but I'm in the dark wrt Maven. Can you guide us? -- Pierre -Mark Daniel Draws wrote: In the last days I've tested the realy nice maven. But for the applications web-tier I need the jakarta-taglibs And I can't find any remote repository including them. Is there anybody who knows a remote repository including the jakarta-taglibs. Or knows anybody another solution How to simply declare the dependencies and resolve them in the build process. thx daniel - 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: JSTL fmt:formatDate bug ???
But would this work?
fmt_rt:formatDate value=${row.TIME}
timeZone=%= Constants.TIMEZONE %
pattern=dd-MM- 'at' HH:mm/
I'm using both rt and EL in the same tag ?
No. It is one or the other. Cannot mix within the same action.
However, you can mix both EL- and RT- based actions as follows:
(from the spec)
fmt:message key=attendanceAgeAverage
fmt:param value=${totalParticipants}
fmt_rt:param value=%=Stats.ageAverage(participants)%/
/fmt:message
-- Pierre
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSTL fmt:formatDate bug ???
Riaan Oberholzer wrote:
Actually
fmt:formatDate value=${row.TIME}
timeZone=%= Constants.TIMEZONE %
pattern=dd-MM- 'at' HH:mm/
does not work
fmt:formatDate value=${row.TIME}
timeZone=Europe/London
pattern=dd-MM- 'at' HH:mm/
does !!!
( Constants.TIMEZONE = =Europe/London)
So the java scriplet %= xxx % is not allowed?
It depends. If you're on a JSP 2.0 container (JSTL 1.1), then this works.
It won't on a JSP 1.2 container (JSTL 1.0).
In JSTL 1.0, you need to use the RT libraries to
use rtexprvalues. See the spec for details.
-- Pierre
--- Martin van Dijken [EMAIL PROTECTED] wrote:
Try:
fmt:setLocale value=nl_NL/
fmt:formatDate value=${obj}
timeZone=Europe/London type=time/
Or:
fmt:setLocale value=en_GB/
fmt:formatDate value=${obj}
timeZone=Europe/London type=time/
It might be that this actually changes something.
Personally I've found
the whole Locale business very confusing and
illogical to work with, but
that's just my personal frustration.
Martin
-Original Message-
From: Riaan Oberholzer
[mailto:[EMAIL PROTECTED]
Sent: woensdag 25 februari 2004 10:48
To: Tag Libraries Users List
Subject: RE: JSTL fmt:formatDate bug ???
I'm a bit lost here can you give me an example
of
what I should give to jstl to print the time as
Europe/London ?
Thanks
Charl
--- Martin van Dijken [EMAIL PROTECTED]
wrote:
Hey Riaan,
Try fiddling around with setting the locale in
JSTL.
In your example
code you create a SimpleDateFormat with a
pattern as argument. JSTL
uses the constructor with a Locale as additional
parameter.
Grtz,
Martin
-Original Message-
From: Riaan Oberholzer
[mailto:[EMAIL PROTECTED]
Sent: woensdag 25 februari 2004 8:18
To: Tag Libraries Users List
Subject: RE: JSTL fmt:formatDate bug ???
Could you post the code to manually format
the
date?
I can easily compare that to what is being
done
by
the JSTL implementation and give you some
feedback
on that.
Something to the extend of:
static
{
SimpleDateFormatter sdf = new
SimpleDateFormatter(-MM-dd HH:mm);
sdf.setTimeZone(TimeZone.getTimeZone(Europe/London);
}
user inputs time in above format in jsp, then
I
do:
sdf.parseDate(inputtedDate) and do a getTime
and
then
create a java.sql.Timestamp with the long
value
and
put that in the DB. Mysql displays is as one
hour
later, the Dutch time, which is expected.
When displaying it manually, I use the same
sdf
above
and do something like:
sdf.formatDate(new
Date(resultSet.getTimestamp(time).getTime())).
Not 100% sure, as I do not have the code with
me,
but
somthing to this extend. The sdf is a static
in a
singleton utility class.
And, as I said, it only gets messed up after
DST
kicks
in. Maybe Europe/London is somehow (wrongly)
interpreted as GMT?
PS Thanks for hosting your application in
our
fine
little country:)
I live here, but I'm not Dutch. :)
__
Do you Yahoo!?
Yahoo! Mail SpamGuard - Read only the mail you
want.
http://antispam.yahoo.com/tools
-
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]
__
Do you Yahoo!?
Yahoo! Mail SpamGuard - Read only the mail you
want.
http://antispam.yahoo.com/tools
-
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]
__
Do you Yahoo!?
Yahoo! Mail SpamGuard - Read only the mail you want.
http://antispam.yahoo.com/tools
-
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: how to use methods with parameters
is it possible to use JSTL for an expression like
%=calculateDays(startDate, endDate) % ???
probably not, but I am too new to JSTL to figure it out by myself. Could
someone advise me?
This could be possible through an EL function (introduced in JSP 2.0).
The syntax would be as follows:
${acme:calculateDays(startDate, endDate)}
You'd have to define in one of your classes a static method calculateDays with the
proper
signature (Date, Date). The name, class, and signature would then have to be defined
within a function element in a TLD.
Here is a snapshot of 'fn.tld' for the standardized functions
in JSTL 1.1:
---
?xml version=1.0 encoding=UTF-8 ?
taglib xmlns=http://java.sun.com/xml/ns/j2ee;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://java.sun.com/xml/ns/j2ee web-jsptaglibrary_2_0.xsd
version=2.0
descriptionJSTL 1.1 functions library/description
display-nameJSTL functions/display-name
tlib-version1.1/tlib-version
short-namefn/short-name
urihttp://java.sun.com/jsp/jstl/functions/uri
function
description
Tests if an input string contains the specified substring.
/description
namecontains/name
function-classorg.apache.taglibs.standard.functions.Functions/function-class
function-signatureboolean contains(java.lang.String,
java.lang.String)/function-signature
example
lt;c:if test=${fn:contains(name, searchString)}
/example
/function
...
---
-- Pierre
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problems with JSTL 1.1 and Tomcat 5 : UnresolvableException: $prefix:javax.servlet.include.query_string
To make things easier, make sure you run Tomcat using J2SE 1.4.2. You can find the details at: http://jakarta.apache.org/taglibs/doc/standard-doc/standard/GettingStarted.html -- Pierre Aadi Deshpande wrote: Hi, I'm tryin to use Tomcat 5 and the newly released JSTL 1.1 and I get the following error whenever I try to do a x:anything? I've gotten this same error under the Beta 1 running under Tomcat 5. Does anyone have any insight into why I would be getting this error? I thought the JSTL was tested under Tomcat 5, so I'm not sure what I am doing wrong. Thanks in advance for any help, -a org.apache.taglibs.standard.tag.common.xml.UnresolvableException: $prefix:javax.servlet.include.query_string org.apache.taglibs.standard.tag.common.xml.XPathUtil$JstlVariableContext.notull(Unknown Source) org.apache.taglibs.standard.tag.common.xml.XPathUtil$JstlVariableContext.getVariableValue(Unknown Source) org.apache.taglibs.standard.tag.common.xml.XPathUtil$JstlVariableContext.getVariableOrParam(Unknown Source) org.apache.taglibs.standard.tag.common.xml.XPathUtil.fillVarStack(Unknown Source) org.apache.taglibs.standard.tag.common.xml.XPathUtil.selectNodes(Unknown Source) org.apache.taglibs.standard.tag.common.xml.ForEachTag.prepare(Unknown Source) javax.servlet.jsp.jstl.core.LoopTagSupport.doStartTag(Unknown Source) org.apache.jsp.core.skeleton.mom_005frewards_005fcallout_jsp._jspx_meth_x_forEach_0(mom_005frewards_005fcallout_jsp.java:2138) org.apache.jsp.core.skeleton.mom_005frewards_005fcallout_jsp._jspx_meth_cms_randomSet_0(mom_005frewards_005fcallout_jsp.java:2113) org.apache.jsp.core.skeleton.mom_005frewards_005fcallout_jsp._jspService(mom_005frewards_005fcallout_jsp.java:134) org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:133) javax.servlet.http.HttpServlet.service(HttpServlet.java:856) org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:311) org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:301) org.apache.jasper.servlet.JspServlet.service(JspServlet.java:248) javax.servlet.http.HttpServlet.service(HttpServlet.java:856) org.apache.taglibs.standard.tag.common.core.ImportSupport.acquireString(Unknown Source) org.apache.taglibs.standard.tag.common.core.ImportSupport.doEndTag(Unknown Source) org.apache.jsp.account.callouts.index_005fgrocerycardform_005fcallout_jsp._jspx_meth_c_import_0(index_005fgrocerycardform_005fcallout_jsp.java:579) org.apache.jsp.account.callouts.index_005fgrocerycardform_005fcallout_jsp._jspx_meth_c_otherwise_0(index_005fgrocerycardform_005fcallout_jsp.java:555) org.apache.jsp.account.callouts.index_005fgrocerycardform_005fcallout_jsp._jspx_meth_c_choose_0(index_005fgrocerycardform_005fcallout_jsp.java:284) org.apache.jsp.account.callouts.index_005fgrocerycardform_005fcallout_jsp._jspService(index_005fgrocerycardform_005fcallout_jsp.java:128) org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:133) javax.servlet.http.HttpServlet.service(HttpServlet.java:856) org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:311) org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:301) org.apache.jasper.servlet.JspServlet.service(JspServlet.java:248) javax.servlet.http.HttpServlet.service(HttpServlet.java:856) org.apache.taglibs.standard.tag.common.core.ImportSupport.acquireString(Unknown Source) org.apache.taglibs.standard.tag.common.core.ImportSupport.doEndTag(Unknown Source) org.apache.jsp.loyalty_005findex_jsp._jspx_meth_c_import_1(loyalty_005findex_jsp.java:419) org.apache.jsp.loyalty_005findex_jsp._jspService(loyalty_005findex_jsp.java:126) org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:133) javax.servlet.http.HttpServlet.service(HttpServlet.java:856) org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:311) org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:301) org.apache.jasper.servlet.JspServlet.service(JspServlet.java:248) javax.servlet.http.HttpServlet.service(HttpServlet.java:856) org.apache.taglibs.standard.tag.common.core.ImportSupport.acquireString(Unknown Source) org.apache.taglibs.standard.tag.common.core.ImportSupport.doEndTag(Unknown Source) org.apache.jsp.core.skeleton.layout_005fno_005frightnav_jsp._jspx_meth_c_import_4(layout_005fno_005frightnav_jsp.java:650) org.apache.jsp.core.skeleton.layout_005fno_005frightnav_jsp._jspx_meth_c_if_2(layout_005fno_005frightnav_jsp.java:625) org.apache.jsp.core.skeleton.layout_005fno_005frightnav_jsp._jspx_meth_c_forTokens_1(layout_005fno_005frightnav_jsp.java:592) org.apache.jsp.core.skeleton.layout_005fno_005frightnav_jsp._jspx_meth_c_when_3(layout_005fno_005frightnav_jsp.java:562)
Announcing standard-1.1.0 and standard-1.0.5
The Jakarta-Taglibs team is proud to announce two new releases of the standard tag library, an implementation of the JSP Standard Tag Library (JSTL). standard-1.1.0 First official release of our implementation of the JSTL 1.1 specification (JSR-052). Requires a minimum of a JSP 2.0 container, such as Tomcat 5.x. standard-1.0.5 Implements the JSTL 1.0 specification (JSR-052). Requires a minimum of a JSP 1.2 container, such as Tomcat 4.x. For more information on the standard taglib, please see: standard 1.1.0: http://jakarta.apache.org/taglibs/doc/standard-doc/intro.html standard 1.0.5: http://jakarta.apache.org/taglibs/doc/standard-1.0-doc/intro.html For more information on Tomcat, please see: http://jakarta.apache.org/tomcat - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Getting web app context?
Since you tried c:url value=Action.do/, and said it did not
work...
It would also work with the following:
c:url value=/Action.do var=url1/
c:url value=Foo.do var=url2
c:param name=_doneURI value=${url1}/
/c:url
a href='c:out value=${url2}/'Link/a
Your URL has to start with / to have the context
path prepended.
From the spec, section 7.5:
The URL must be either an absolute URL starting with a scheme
(e.g. http:// server/context/page.jsp) or a relative URL as
defined by JSP 1.2 in JSP.2.2.1 Relative URL Specification. As a
consequence, an implementation must prepend the context path to a
URL that starts with a slash (e.g. /page2.jsp) so that such URLs
can be properly interpreted by a client browser.
-- Pierre
otisg wrote:
Thank you, that does it. I just found it in Sun's JSTL
tutorial. I hate when this happens :)
Otis
Get your own 800 number
Voicemail, fax, email, and a lot more
http://www.ureach.com/reg/tag
On Thu, 8 Jan, Kris Schneider ([EMAIL PROTECTED]) wrote:
pageContext.request.contextPath
Quoting otisg [EMAIL PROTECTED]:
Hello,
I am trying to do something like this in a JSP:
a href=
c:url value=Foo.do
c:param name=_doneURI value=/MYAPP/Action.do/
/c:url/a
That /MYAPP part is hard-coded, and I would like ot replace
it
with a piece of JSTL that would always put the name of the
current web application context there.
Is there a way to do this in JSTL?
I am looking at the JSTL reference (Appendix from JSTL in
Action), but see nothing that will do that but I
suspect
that I'm just not seeing it, and that there is a nice,
elegant
way of doing this using JSTL.
I've tried using the following in place of MYAPP above:
c:url value=Action.do/, but that didn't work :(
I actually couldn't even get this to work:
c:out value=c:url value=Action.do//
Thanks,
Otis
--
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]
-
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: XML processing with target namespace documents
That should tell you why this does not work.
http://marc.theaimsgroup.com/?l=taglibs-userm=103723631220244w=2
And no, the expert group did not come to a concensus on this
for JSTL 1.1 and this will have to be tackled in JSTL.next.
-- Pierre
Kralidis,Tom [Burlington] wrote:
Hi,
We've been using JSTL 1.0, with success, to process some web services within
our software.
When processing an XML document which has a target namespace, i.e.:
MyOutput version=1.0.0 xmlns=http://localhost/myoutput;
xmlns:gml=http://www.opengis.net/gml;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://localhost/myoutput
http://localhost/watershed.xsd;
With the following code snippet:
...
c:import url=${requestURL} varReader=xmlSource
x:parse var=doc xml=${xmlSource} scope=application /
/c:import
x:out select=$doc/MyOutput/@version/
No value is returned on x:out. If the XML document has no target namespace,
all works as expected.
Any suggestions here? We are starting to deal with alot of XML which is
designed in this fashion. We also run into the same issue for XML document
with elements which have namespaces, i.e. gml:nametom/gml:name.
Thanks much
..Tom
=
Tom Kralidis
Systems Scientist
Environment Canada
Tel: +01-905-336-4409
http://www.ec.gc.ca/cise/
=
-
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: Serialising javax.servlet.jsp.jstl.sql.ResultImpl
I checked with the gurus, and the conclusion is as expected: while having ResultImpl implement interface Serializable exposes a portability issue, it shouldn't be a spec violation. I therefore suggest we fix ResultImpl to implement interface Serializable, and insert a comment in the Release Notes stating that relying on the serializability of Result objects might not be portable across different implementations of the JSTL spec. Please let me know if there is any other related issue. -- Pierre [Shawn, thanks for dropping the law books a few minutes to come help us out :-)] Shawn Bayern wrote: On Tue, 16 Dec 2003, Kris Schneider wrote: Thanks for looking into it. To be honest, I'm surprised it took this long to surface ;-). As for whether Result should actually extend Serializable, I'm usually of the mind that an interface shouldn't extend Serializable and that it's an implementation detail. Consider the core collection interfaces and classes: neither Map nor SortedMap extend Serializable and AbstractMap doesn't implement it. TreeMap, however, does implement it. Another example would be the ResultSet and RowSet interfaces, neither of which extend Serializable. The important distinction here isn't between interface and implementation but between specification and implementation. Regardless whether an interface should typically be extended by an interface or implemented by a class (which I'll address in a moment), Pierre's concern here is that the enhancement request shouldn't be addressed by an implementation of the JSTL specification on its own. While I don't think it would strictly violate the JSTL specification for a JSTL implementation to have one of its classes (which implements a specified interface) implement another arbitrary interface, it would certainly be poor practice for users to rely on this nonstandard behavior (and thus probably irresponsible for an implementation to promote it). As for the specific point about whether interfaces should extend or implementations should implement, I don't think the analogies you raise are apposite: Map indeed doesn't extend Serializable, but this is only because there's no call for all implementations of Map to be Serializable. The JSTL specification could conceivable require that all implementations of a standard interface also implement Serializable, but the most elegant way for it to accomplish this is to have the standard interface extend Serializable itself. Indeed, this approach is very common: note the number of subinterfaces to Serializable (i.e., the number of interfaces that extend Serializable) in the J2SDK 1.4 API. Shawn - 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: Serialising javax.servlet.jsp.jstl.sql.ResultImpl
Ideally, javax.servlet.jsp.jstl.sql.Result should be spec'ed as implementing the Serializable interface, so serialization is not left up to the implementor of the spec but is consistently applied across all implementations of the spec. We'll make sure this is fixed in the next rev of the spec. In the meantime, is it a spec violation to have an implementation of the Result interface (in our case ResultImpl) implement the Serializable interface? Maybe it is not, as Kris argues. However, the danger here is that if one vendor does support Serializable and the other does not, then a webapp would not be portable. And the specs are very strict on compatibility/portability issues... I'll consult with a few spec gurus and report back... Thanks, -- Pierre Kris Schneider wrote: A couple of other points to consider. According to the Serialization Spec, adding Serializable to a class is a compatible change. In addition, a serializable class must have access to the no-arg constructor of its first nonserializable superclass. Since ResultImpl extends Object, it meets that requirement as well. Quoting Kris Schneider [EMAIL PROTECTED]: Here's a comment from ResultImpl.java: It is not part of the JSTL API; it serves merely as a back-end to ResultSupport's static methods. Also, the 1.0 spec only references Result and ResultSupport. I don't see how it's a spec issue if ResultImpl is changed to implement Serializable. It *would* be a spec issue for Result to extend Serializable, but that doesn't seem necessary. Is it just because the class is packaged in javax.servlet.jsp.jstl.sql as opposed to org.apache.taglibs.standard? Quoting Felipe Leme [EMAIL PROTECTED]: Kris, There was already a bug opened for this issue (can't find which one while bugzilla is down) and it was marked as RESOLVE LATER because the problem is in the JSTL specification, not at Jakarta's implementation itself. As JSTL 1.1 specification has reached its final status, this bug can't be fixed now, only on the next specification. Felipe Kris Schneider wrote: While it could be argued it's not a bug, it certainly would be a nice enhancement to have ResultImpl implement Serializable. There are, however, a couple of things you can do in the meantime. Depending on your needs, you could just store the SortedMap[] returned by getRows in the session. Or you could create your own Result implementation that is serializable - the code in ResultImpl isn't really all that complex. Unfortunately, Bugzilla appears to be unreachable or I'd see about submitting an enhancement request... -- 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: Simple question, taglibs on eclipse-specific
Manos, What you're doing seems correct. To make sure there is no typo anywhere, why don't you just try a simple webapp with tomcat 5 only. If it works, then there's definitely a problem with eclipse and I'd suggest you try an eclipse support list. -- Pierre Manos Papantoniou wrote: I have a relatively basic question, and I expect someone who has been using taglibs with eclipse to be able to answer it. I have very recently started using eclipse, JSP and taglibs so please excuse me if you find this question trivial. I have looked in the archives and couldn't find the answer, I suppose this is too basic for most people to ask, but since I can't solve it for a few hours... here is the problem: I am using eclipse 2.1, with tomcat 5.0.12beta and the Lomboz plugin on a windows machine. Java version is java version 1.4.2_01 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_01-b06) Java HotSpot(TM) Client VM (build 1.4.2_01-b06, mixed mode) I created a Lomboz J2EE project, and then a web module inside the project. Simple JSP pages created in the module are deployed fine (when I say simple I mean without taglibs). Also, the JSP 2.0 Expresion Language works fine (I had to change the web.xml definition for that, since the one that is automatically created by lomboz refers to the older style 2.3 but we want 2.4 for the EL to work), so my web.xml starts like that: ?xml version=1.0 ? web-app version=2.4 xmlns=http://java.sun.com/xml/ns/j2ee; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://java.sun.com/xml/ns/j2ee web-app_2_4.xsd Now I have tried to add a taglib statement in the first line of the jsp page and the eclipse editor flags it as an error. The statement is: %@ taglib prefix=c uri=http://java.sun.com/jsp/jstl/core; % as the taglibs readme states: USING THE STANDARD TAG LIBRARY To use this distribution with your own web applications, simply copy the JAR files in the 'lib' directory (jstl.jar and standard.jar) to your application's WEB-INF/lib directory (add the other dependencies as well if your runtime does not already provide them). Then, import JSTL into your pages with the following directives: CORE LIBRARY %@ taglib prefix=c uri=http://java.sun.com/jsp/jstl/core; % I have followed the readme instructions that come with taglibs (the precise taglibs file I downloaded is jakarta-taglibs-20031006.zip). I copied the 2 libraries from the jakarta-taglibs-20031006\jakarta-taglibs-standard-1.1.0-B1\lib folder, jstl.jar and standard.jar to the WEB-INF\lib folder of my project, but still the error is there. I have tried changing the uri to all variations, removing the /jsp part, including the _rt in the end and everything. I have tried adding the required libraries (.jar files) to the eclipse Project Properties / Java Build Path / Libraries, since I think this is probably some internal eclipse configuration issue, and by doing it through the IDE it would generate the required dependencied internally, but the error is still there. Can anyone who uses taglibs with eclipse tell me how do you configure the libraries? I cannot use the taglibs at all if I don't solve this, I have spend several hours looking on the net, on the eclipse site, and the taglibs archive but I cannot find this anywhere, everybody refers to more complex problems. Can someone please help? Thanks - 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: iterator problem
David Liles wrote:
I am trying to use the iterator tag and am unclear on a couple items. I have been using the following example as a template:
iter:forCategories var=athlete items=${athletes}
iter:category value=${athlete.country}
iter:header
h3c:out value=${athlete.country}//h3
/iter:header
iter:body
c:out value=${athlete.name}/br
/iter:body
iter:footer
/iter:footer
/iter:category
/iter:forCategories
Question 1: the value show for items=${athletes}.
is this the reference name for the ArrayList, Collection, etc
given to the object to be iterated?
${athletes} refers to a collection to be iterated over.
In the code I'm trying to work with, when I add a body
element I get a javax/servlet/jsp/JspContext error
This is what I'm trying to work with:
iter:forCategories var=f items=${folders}
iter:body
Folders To Be Displayed
/iter:body
/iter:forCategories
Can someone please educate me as to what I might be doing wrong?
Give us more details and we might be able to help.
Ideally, a small snippet of code that shows your problem and that
we can reproduce. That should be easy.
-- Pierre
Thanks
-
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: Feature request in c:url?
Jeroen,
This issue was first raised by Andreas in bug #23319.
(http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23319)
I've brought it up to the expert group and it will, as mentioned
by Martin, require a change to the spec.
I've just added a comment to that bug stating that
unfortunately the JSTL 1.1 Maintenance Release spec is now frozen,
and the fix will have to wait for the next release.
The change that the expert group has agreed on so far is to add
one new attribute, 'escapeAmp', to escape the ampersand character.
Default value will be false (to be backwards compatible).
HTH,
-- Pierre
Martin van Dijken wrote:
Hey Jeroen,
Sounds sensible, considering the fact that it is even a requirement of standard HTML 4.01. However, this is a modification of the spec I think. You might want to get in touch with them, or try the taglib-dev dept.
Grtz,
Martin van Dijken
-Original Message-
From: Vianen, Jeroen van [mailto:[EMAIL PROTECTED]
Sent: dinsdag 7 oktober 2003 11:25
To: '[EMAIL PROTECTED]'
Subject: Feature request in c:url?
To be able to write correct XHTML 's in the querystring need
to be escaped.
To do so, I use the following code:
c:set var=a value=A/
c:set var=b value=B/
c:url var=theUrl value=whatever.jsp
c:param name=a value=${a}/
c:param name=b value=${b}/
/c:url
a href=c:out value=${theUrl} escapeXml=true/Link to
whatever/a
This will return a correctly XML / XHTML escaped URL:
a href=whatever.jsp?a=Aamp;b=B.../a
Would it be possible in a future version of the JSTL to
combine these two
tags as follows:
c:url value=whatever.jsp escapeXml=true
c:param name=a value=${a}/
c:param name=b value=${b}/
/c:url
What do you think?
Jeroen
-
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: c:import: relative links inside WEB-INF don't work
Manolo Ramirez T. wrote: Hi, I'm using jsp's outside WEB-INF to include prueba and prueba1, I forget to say that. In that case, you'd want the following: %@ taglib uri=http://java.sun.com/jstl/core; prefix=c % c:import url=WEB-INF/prueba2.jsp/ -- Pierre _ Manolo Ramirez T. Serge Knystautas wrote: You shouldn't be able to execute JSPs within your WEB-INF, so all 3 of your examples should be forbidden. I think you might want to submit a bug report to whatever servlet engine you're using. - 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: Having trouble with Multiple namespaces reading XML source
Gavin, I cannot talk for the xtags taglib, but for the xml tags of the standard taglib (implementation of JSTL), you have to make sure you access properly a specific node by referring to its namespace using the name() and namespace-uri() functions in XPath. You may want to check that thread in the archive: http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]msgNo=4049 The deferred section of the JSTL 1.1 change log (http://java.sun.com/jstl), says the following: Deferred Changes Provide adequate XML Namespace support for the XML actions JSTL 1.0 does not currently provide adequate support for XML namespaces in XPath expressions. Collaboration between the JSP, JAXP, and JSTL specs is necessary to come up with the proper solution. This will therefore be addressed in the next major revision of JSTL. HTH, -- Pierre Mach, Gavin wrote: Hello everybody, I am new to this group but have been developing a JSP page which reads in an xml source file. I am also using Xtags taglib for XML parsing and processing. A snippet of the xml source looks like below:... INPUT.XML ?xml version=1.0 ? Task SchemaVersion=2.0 Type=ResponseTask xmlns=http://www.lexign.com/schemas/flow; ApplicationData DataItemString ID=4100 Name=EMPLOYEENAME Access=Write Description=Employees nameJoe Bloggs /DataItemString DataItemString ID=4200 Name=ISIDINITIATOR Access=Write Description=ISID1031 /DataItemString /ApplicationData /Task The problem I am having is the xml file is only successfully read when the xmlns attribute of the Task element is removed however the application that creates this xml file cannot allow this so the xmlns attribute has to stay. The JSP file that reads it has the following structure in the head ...(very typical) XMLReaderApp.jsp ?xml version=1.0 encoding=UTF-8? html %@ taglib uri=http://jakarta.apache.org/taglibs/xtags-1.0; prefix=xtags % head % String TXNfile = INPUT.XML; % xtags:parse uri=TXNfile/ ..etc.. I am aware this has to do with a namespace clash and have looked into various resources but to no avail. Could someone please shed some light on this issue. Thanks a bundle in advance. Gavin. - 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: difference between Standard and standard 1.0
deepaksawdekar wrote: On apache site there are two down loads for standard tag libs . standad and standard 1.0 whats the difference between these two . If you click on each one of those links, the answer is right there. And to understand the difference between JSTL 1.0 and JSTL 1.1, please check the JSTL page at http://java.sun.com/jstl. --- standard-1.0/ Standard Taglib 1.0 Release This directory containts the final 1.0 release of the Standard Taglib, Jakara Taglibs's open-source implementation of the JSP Standard Tag Library (JSTL). JSTL is a standard under the Java Community Process. --- standard/ Standard Taglib 1.1.x Releases This directory contains releases for the 1.1.x versions of the Standard Tag Library, Jakarta Taglibs's open-source implementation of the JSP Standard Tag Library (JSTL), version 1.1. JSTL is a standard under the Java Community Process. Standard-1.1.x requires a JSP 2.0 container, while Standard-1.0.x requires a JSP 1.2 container. For more information about JSTL, see Sun's JSTL page (http://java.sun.com/jstl) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSTL character encoding
Hans Bergsten wrote: Adam Hardy wrote: Hi Robb, good solution. I suppose this is why it is called 'bleeding edge'! I see tomcat 5 implements servlet spec 2.4 - that is a relief. I checked out the servlet spec 2.4, as you said, there is the following element-list in web.xml specified as 1 or more: locale-encoding-mapping-list locale-encoding-mapping localeja/locale encodingShift_JIS/encoding /locale-encoding-mapping /locale-encoding-mapping-list I shall try it out. Guess I have to learn to be even more bleeding edge and then I won't spend hours wondering what's up! Actually, if you use a Servlet 2.3, JSP 2.0 and JSTL 1.1 combo, the ^^^ Just to make sure there is no confusion, this should read Servlet 2.4. charset you specify with the page directive will be used for the response, no matter how many times setLocale() is called by the JSTL actions. No need to mess with the locale/charset mappings. To make a long story short, the whole i18n area was underspecified in the older specifications, especially the order of precedence between setContentType() and setLocale(). In Servlet 2.4, the charset set by setContentType() is required to win over an implicit charset set by setLocale() (and it's mappings between locales and charsets), and JSP 2.0 is required to call setContentType() with the value defined by the page directive before processing the page. BTW, Hans was instrumental in getting all the spec leads together to sort out the whole issue. You can drink his words :-) (if there's such an expression in English...) -- Pierre So if you still run into this problem with this in TC 5, it's a bug. Hans On 09/29/2003 12:40 PM Nedwick, Robert wrote: I don't really understand why the behavior that is described in the specification is desirable, especially since the JSTL is overriding explicit page directives that set the response character set, and you don't have a clue that it is doing it unless you're aware of this side effect of the fmt tag library. I never got a response to a similar question that I had posted on one of the tag lib mailing lists, but based on the fact that its so well documented in the spec, I believe that someone must have had a reason for this behavior. I think that part of the problem is that the next servlet specification (2.4) provides a standard method of mapping of a Locale to a character encoding via web.xml, and therefore the JSTL could perform the setLocale() method in such a way that your page encoding was not messed up. Anyway, the solution that I came up with was to use a ServletFilter that intercepted all calls to our presentation tier. The filter would set the request encoding and the response charset to UTF-8. It would also pass a custom subclass of HttpServletResponseWrapper named UTF8Response to the next item in the chain. UTF8Response basically just any method that could set the response character set to be an empty operation. It also would always return UTF-8 for the response character set. By using the custom response class, in conjunction with the ServletFilter, we managed to get everything to work fine in Tomcat 4.1, Oracle 9iAS 9.0.3, and Weblogic 6.1 (service pack 5 is required for Weblogic 6.1 due to bugs in the ServletFilter implementation 6.1). FYI, Oracle 9iAS still has some other character encoding issues with JSP tags that use BodyContent so the Oracle container still doesn't work 100% even after using the filter/response wrapper. Let me know if you have need any more details than this. Good Luck, Robb - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: standard-1.0.4 and standard-1.1.0-B1 now available
Since a few people have asked... You can get a link to the JSTL 1.1 Maintenance Release spec at http://java.sun.com/jstl. Scroll to the 'Specification' section and you will see a link to the JSTL 1.1 Maintenance release spec. -- Pierre Andreas Schildbach wrote: Hello everyone, I just saw that there is now an early access of the JSTL 1.1 implementation. Where can I get the specification? I could not find it anywhere. Regards, Andreas Pierre Delisle wrote: The Jakarta-Taglibs team is proud to announce two new releases of the standard tag library, an implementation of the JSP Standard Tag Library (JSTL). standard-1.0.4 Implements the JSTL 1.0 specification (JSR-052). Requires a minimum of a JSP 1.2 container, such as Tomcat 4.x. standard-1.1.0-B1 Early access (not yet Final) of an implementation of the JSTL 1.1 specification (JSR-052). Requires a minimum of a JSP 2.0 container, such as Tomcat 5.x. For more information on the standard taglib, please see: standard 1.1.0-B1: http://jakarta.apache.org/taglibs/doc/standard-doc/intro.html standard 1.0.4: http://jakarta.apache.org/taglibs/doc/standard-1.0-doc/intro.html For more information on Tomcat, please see: http://jakarta.apache.org/tomcat - 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: fmt:param not working as expected...
From bug #14590:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14590
...
This is not a bug in JSTL, but a peculiarity of how a single
quote is interpreted by java.text.MessageFormat.
For more details, you may want to check bug
reports 4293229 and 4321513 in the java bug database
(http://developer.java.sun.com/developer/bugParade).
The simple rule is as follows:
If there is a {0} placeholder in a message string,
single quotes have to be doubled.
-- Pierre
Billy Bacon wrote:
Nope, I'm not using Resin. I did however get it to work with someone else's
suggestion... For those who are interested
In my Messages.properties file I needed to escape the single qoute in the
word Can't... Notice the 2 single quotes ''
md.tree.label.feedback1=Can''t find the {0}? Mail
Then in my JSP I did the following...
fmt:message key=md.tree.label.feedback1
fmt:paramc:out value=${mdTreeForm.map.itemDesc}//fmt:param
/fmt:message
Thanks to those who offered suggestions!
- Billy -
On 9/26/03 12:31 PM, Karr, David [EMAIL PROTECTED] wrote:
You're not using Resin, are you? Resin has their own JSTL
implementation, which might be different from the Jakarta
implementation.
-Original Message-
From: Billy Bacon [mailto:[EMAIL PROTECTED]
I tried this after your suggestion and I still get the same
result. Are you
doing something differently?
fmt:message key=md.tree.label.feedback1
fmt:paramc:out value=${mdTreeForm.map.itemDesc}//fmt:param
/fmt:message
On 9/26/03 3:54 AM, Martin van Dijken [EMAIL PROTECTED] wrote:
Hey Billy,
I've got your example working with one little difference,
though it may not be
significant. I've got the value within the param tags
instead of as value.
Grtz,
Martin
-Original Message-
From: Billy Bacon [mailto:[EMAIL PROTECTED]
I searched the archives and didn't see any issues like this
listed. Can
anyone help me out here?
I original had all struts tags and in my messages.properties
file where all
my localized content is stored I had the following entry...
md.tree.label.feedback1=Can't find the {0}? Mail
Notice the {0} which is a place holder for an argument/parameter...
This was working fine with Struts but the following is not
working in JSTL..
fmt:message key=md.tree.label.feedback1
fmt:param value=xyz/
/fmt:message
For some reason it's printing out Can't find the {0}?
Mail and not
replacing {0} with 'xyz'...
-
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: Issue with formatDate tags
[Please note this has also been added as a comment to bug 22892.]
The behavior of the formatting tags is in accordance with the
JSTL spec.
With respect to the following exception:
java.lang.IllegalStateException: Response is already committed!
the spec clearly states in section 8.4 that:
This assumes that the response is buffered with a big enough buffer size, since
ServletResponse.setLocale() and ServletResponse.setContentType()
must be called before ServletResponse.getWriter() in order for the specified
locale or charset to affect the construction of the writer.(1)
(1). It also assumes that the JSP container doesn't call getWriter() until it's
about to flush the buffer. An errata has been published for the JSP 1.2
specification
to clarify this.
As you mentioned, you have to make sure that you have a big enough
buffer, as well as verify that your container vendor complies with
this errata of the JSP spec.
Finally, the language regarding this whole issue as been clarified
in JSTL 1.1 as follows:
Summary:
Response Encoding
The way formatting actions influence the encoding of the response has been
clarified in sections 8.4 and 8.10. Repeated calls to
ServletResponse.setLocale() will affect the character encoding of the
response only if it has not already been set explicitely.
Please check the JSTL 1.1 spec for more details
(http://java/sun/com/jstl)
Hope this helps,
-- Pierre
MEIN, Christopher, FM wrote:
Hello
We have been having trouble with the formatDate and formatNumber tags. I
have outlined in some detail an issue in the bug tracker (22892) but in
brief every time a format tag runs if no Locale is set it creates a default
Locale and then calls ServletResponse.setLocale(). Reading the JavaDoc for
ServletResponse.setLocale()
Sets the locale of the response, setting the headers (including the
Content-Type's charset) as appropriate. This method should be called before
a call to getWriter().
What happens on our large pages is that, running under OC4J, we get a
IllegalStateException response already committed error. Removing the
formatDate tag corrects the problem. the same occurs with formatNumber.
My main question is why is the code in
org.apache.taglibs.standard.tag.common.fmt.SetLocaleSupport
static void setResponseLocale(PageContext pc, Locale locale) {
// set response locale
ServletResponse response = pc.getResponse();
response.setLocale(locale);
// get response character encoding and store it in session attribute
if (pc.getSession() != null) {
pc.setAttribute(RequestEncodingSupport.REQUEST_CHAR_SET,
response.getCharacterEncoding(),
PageContext.SESSION_SCOPE);
}
}
written like it is? The Locale value gets set every time the tag runs so it
isn't being cached properly in any case. I am wondering if anybody else is
getting this type of error?
We have worked around the problem by commenting out the offending line. I
think the caching of the Locale needs to be looked at as the Locale is
always calculated as well.
Chris Mein
***
This e-mail is intended only for the addressee named above.
As this e-mail may contain confidential or privileged information,
if you are not the named addressee, you are not authorised to
retain, read, copy or disseminate this message or any part of it.
The Royal Bank of Scotland plc is registered in Scotland No 90312
Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB
Regulated by the Financial Services Authority
Visit our website at http://www.rbs.co.uk/CBFM/
***
-
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: According to TLD or attribute directive in tag file, attribute test does not accept any expression
Hi Rick, Hummm, a JSTL 1.0 based webapp should run unchanged on a JSP 2.0 container. All details on backwards compatibility are provided in the new JSTL 1.1 spec, appendix A (see http://java.sun.com/jstl). Please have a look, and send me simple war files that reproduce your problem(s). The migration to JSP 2.0 and/or JSTL 1.1 should definitely be smoother than the one you've experienced ;-) -- Pierre Rick Ross wrote: That is the error I kept getting with the simplest of JSTL in a page now that I converted over to Tomcat 5.0.9 from 4.1.24 After a wee bit of trial and error, I realized that the _rt libraries are required with JSP 2. Perhaps others will have known this off the bat, but it didn't occur to me until I got slapped by it (my wife can vouch for that as my standard learning style). So, as with Tomcat 4.1.x, you don't need anything in your web.xml nor any TLDs explicitly hanging around (so long as they are in the jar) However, you will need to reference the rt versions of all of the functionality. So every: %@ taglib uri=http://java.sun.com/jstl/core; prefix=c % Needs to be replaced with %@ taglib uri=http://java.sun.com/jstl/core_rt; prefix=c % or better yet with the explicit xmlns: declaration (which I haven't bothered with yet.) R - 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: writing a custom tag that can use EL
Adam Hardy wrote: Does J2EE 1.4 include JSP2.0? Yes. Is JSTL part of JSP2.0? No. JSTL 1.1 is the version that synchronizes with JSP 2.0. JSTL 1.0 requires at least a JSP 1.2 container. JSTL 1.1 requires at least a JSP 2.0 container. JSTL is not currently part of the J2EE platform. -- Pierre - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: writing a custom tag that can use EL
Felipe Leme wrote: Pierre, Now that you mention it, is there any plans to officially include it on J2EE1.4? JSTL 1.1 is bundled with the J2EE 1.4 RI (Reference Implementation), but it is not part of the J2EE platform per se. I think JSTL is not in the current J2EE 1.4 specification, even though its implementation is included on j2sdkee1.4. Correct. -- Pierre - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: a question about jstl1.1
lieutenant wrote: Hi, i want to synchronize the source(in development) of jstl1.1 RI ,Is the cvs address this: CVS_HOME: :pserver:[EMAIL PROTECTED]:/home/cvspublic jstl_dir: jakarta-taglibs/standard Yes. -- Pierre - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: forTokens problem
Howard Lin wrote:
Thanks, Pierre, I have another question. According to JSTL, the delims is mandatory but
in Java, when StringToken created, if delimiter is not there, then the default delimiter
is used. Is it possible for JSTL remove mandatory requirement for delims attribute
for forToken tag (so it works like in Java)?
Howard,
I agree this would make more sense (and it is not clear to me why we did not do
it this way in the first place). At any rate, I've added this to the TODO list
for JSTL.next.
Thanks,
-- Pierre
Howard
-Original Message-
From: Pierre Delisle [mailto:[EMAIL PROTECTED]
Sent: Friday, June 06, 2003 9:30 PM
To: Tag Libraries Users List
Subject: Re: forTokens problem
Howard Lin wrote:
I'm trying to use c:forTokens to parse a string, using \n
as the delimiter and it seems it doesn't work. The jsp code
is like this:
c:forTokens items=my_string delims=\n var=foo
tdc:out value=${foo}//td
/c:forTokens
${foo} shows the whole entire string instead of the
token. but if I use StringTokenizer to parse the string in a
script, I got the individual token. So I suspect c:forTokens
might be the problem. Thanks,
Howard Lin wrote:
I'm trying to use c:forTokens to parse a string, using \n
as the delimiter and it seems it doesn't work. The jsp code
is like this:
c:forTokens items=my_string delims=\n var=foo
tdc:out value=${foo}//td
/c:forTokens
${foo} shows the whole entire string instead of the
token. but if I use StringTokenizer to parse the string in a
script, I got the individual token. So I suspect c:forTokens
might be the problem. Thanks,
Howard,
It is not a problem with c:forTokens, but rather the fact that
there is no way to pass special Java characters as String literals
in an attribute value.
The \n is being interpreted as the two characters '\' and
'n'.
One way to get the behavior you want is to make sure the
\n is really passed as a Java String.
For example:
JSTL 1.1 (assuming myString is a scoped variable)
c:forTokens items=${myString} delims='%=\n%' var=token
c:out value=${token}/br
/c:forTokens
JSTL 1.0 (assuming myString is a scripting variable)
c_rt:forTokens items=%=myString% delims='%=\n%'
var=token
c:out value=${token}/br
/c_rt:forTokens
or
%
String lf = \n;
pageContext.setAttribute(lf, lf);
%
c:forTokens items=${myString} delims=${lf} var=token
c:out value=${token}/br
/c:forTokens
-- Pierre
[and yes, maybe the EL should recognize these special character
sequences... passed the issue to the JSP spec leads]
-
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: forTokens problem
Howard Lin wrote:
I'm trying to use c:forTokens to parse a string, using \n as the delimiter and it
seems it doesn't work. The jsp code is like this:
c:forTokens items=my_string delims=\n var=foo
tdc:out value=${foo}//td
/c:forTokens
${foo} shows the whole entire string instead of the token. but if I use
StringTokenizer to parse the string in a script, I got the individual token. So I suspect
c:forTokens might be the problem. Thanks,
Howard Lin wrote:
I'm trying to use c:forTokens to parse a string, using \n as the delimiter and it
seems it doesn't work. The jsp code is like this:
c:forTokens items=my_string delims=\n var=foo
tdc:out value=${foo}//td
/c:forTokens
${foo} shows the whole entire string instead of the token. but if I use
StringTokenizer to parse the string in a script, I got the individual token. So I suspect
c:forTokens might be the problem. Thanks,
Howard,
It is not a problem with c:forTokens, but rather the fact that
there is no way to pass special Java characters as String literals
in an attribute value.
The \n is being interpreted as the two characters '\' and
'n'.
One way to get the behavior you want is to make sure the
\n is really passed as a Java String.
For example:
JSTL 1.1 (assuming myString is a scoped variable)
c:forTokens items=${myString} delims='%=\n%' var=token
c:out value=${token}/br
/c:forTokens
JSTL 1.0 (assuming myString is a scripting variable)
c_rt:forTokens items=%=myString% delims='%=\n%' var=token
c:out value=${token}/br
/c_rt:forTokens
or
%
String lf = \n;
pageContext.setAttribute(lf, lf);
%
c:forTokens items=${myString} delims=${lf} var=token
c:out value=${token}/br
/c:forTokens
-- Pierre
[and yes, maybe the EL should recognize these special character
sequences... passed the issue to the JSP spec leads]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: forTokens problem
Howard Lin wrote:
I'm trying to use c:forTokens to parse a string, using \n as the delimiter and it
seems it doesn't work. The jsp code is like this:
c:forTokens items=my_string delims=\n var=foo
tdc:out value=${foo}//td
/c:forTokens
${foo} shows the whole entire string instead of the token. but if I use
StringTokenizer to parse the string in a script, I got the individual token. So I suspect
c:forTokens might be the problem. Thanks,
Howard Lin wrote:
I'm trying to use c:forTokens to parse a string, using \n as the delimiter and it
seems it doesn't work. The jsp code is like this:
c:forTokens items=my_string delims=\n var=foo
tdc:out value=${foo}//td
/c:forTokens
${foo} shows the whole entire string instead of the token. but if I use
StringTokenizer to parse the string in a script, I got the individual token. So I suspect
c:forTokens might be the problem. Thanks,
Howard,
It is not a problem with c:forTokens, but rather the fact that
there is no way to pass special Java characters as String literals
in an attribute value.
The \n is being interpreted as the two characters '\' and
'n'.
One way to get the behavior you want is to make sure the
\n is really passed as a Java String.
For example:
JSTL 1.1 (assuming myString is a scoped variable)
c:forTokens items=${myString} delims='%=\n%' var=token
c:out value=${token}/br
/c:forTokens
JSTL 1.0 (assuming myString is a scripting variable)
c_rt:forTokens items=%=myString% delims='%=\n%' var=token
c:out value=${token}/br
/c_rt:forTokens
or
%
String lf = \n;
pageContext.setAttribute(lf, lf);
%
c:forTokens items=${myString} delims=${lf} var=token
c:out value=${token}/br
/c:forTokens
-- Pierre
[and yes, maybe the EL should recognize these special character
sequences... passed the issue to the JSP spec leads]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Accessing scope attributes with dotted names using JSTL
Serge Knystautas wrote:
Steve Raeburn wrote:
Thanks, but that's not what I'm trying to accomplish.
It's very common to place beans into session or application scopes with
names such as org.apache.struts.action.ACTION_MESSAGE. This is
similar to
the Java package naming convention and accomplishes the same purpose of
avoiding name collisions.
In order to access the bean, you need to be able to specify a dotted
name,
but you might not always know in which scope it will be found. Hence the
need to be able to specify a dotted bean name in EL.
The problem is that either EL interprets the string as a path to a nested
property or, if you escape the string, as a literal string.
Ultimately, I need to be able to access the
PageContext.findAttribute(java.lang.String name) method using EL, but as
this method does not meet bean property naming conventions I can't
even do
something like ${pageContext[dotted.name]}.
It's true you can't do find attribute with a dotted-name. If you want
to jury rig something, do this...
%!
static class AttributeFascade extends HashMap {
PageContext context;
public AttributeFascade(PageContext context) {
this.context = context;
}
public Object get(Object key) {
return context.findAttribute(key);
}
}
%
%
pageContext.setAttribute(finder, new AttributeFascade(pageContext));
%
c:out value=${finder['dotted.name']} /
You can flesh out AttributeFascade if you want to implement more methods
on Map, maybe make it a regular class, maybe have a taglib that sets
this for you, e.g.,
foo:attributeFascade var=finder /
Anyway, just a thought on how to do this if you must. As you can see,
you start bending the brain in on itself, so that's part of why it was
left off of the spec. ;)
As shown by all emails on the topic, accessing scoped variables with a
dotted name is not as easy as it should be right out of the box.
I'll submit the issue to the JSP spec leads to see if maybe they'd be
willing to amend the EL syntax to make this easier.
[Either adding an extra implicit object such as 'allScopes'
to allow ${allScopes['my.dottted.scoped.var']},
or even maybe allowing something like ${['my.dotted.scoped.var']}).
-- Pierre
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSTL Defined Methods
Chen, Gin wrote: Sorry this was posted not too long ago but I can't find it in the archives. What are the JSTL 1.0 defined functions? (for trimming etc) -Tim See below. Please note that these EL functions are only available in JSTL 1.1. Original Message Subject: Re: Rif: Re: float to int conversion using EL; also how we can use ceil(), floor(), ... Date: Thu, 22 May 2003 11:06:04 -0700 From: Pierre Delisle [EMAIL PROTECTED] Reply-To: Tag Libraries Users List [EMAIL PROTECTED] To: Tag Libraries Users List [EMAIL PROTECTED] References: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Mark R. Diggory wrote: On another side Note: Wouldn't it be good as well to provide a standard set of static methods available in java.lang / java.util in general including things like String concatenation, substrings, comparision, math and dates? Sounds like the start of a Standard EL functions library? JSTL 1.1 includes 16 standardized functions. Length function: - To get the length of a collection or string (length) String manipulation functions: - Change the capitalization of a string (toLowerCase, toUpperCase) - Get a subset of a string (substring, substringAfter, substringBefore) - Trim a string (trim) - Replace characters in a string (replace) - Check if a string contains another string (indexOf, startsWith, endsWith, contains, containsIgnoreCase) - split a string (split) into an array, and join an array into a string (join) - Escape XML characters in the string (escapeXml) The JSTL Expert Group did not go overboard with functions in JSTL 1.1 because it is not clear yet how the EL will evolve in the future. If the EL ever allows method invocation, then many of the above functions would not be required. -- Pierre - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Inline if
Jon,
The conditional operator is very useful, not just in obscure
uses :-).
It has been added to the EL in JSP 2.0.
-- Pierre
Jon Archer wrote:
Am I right in thinking there's no way to condense:
c:choose
c:when test=${someBean.someProperty == someValue}
c:out value=${option1} /
/c:when
c:otherwise
c:out value=${option2} /
/c:otherwise
/c:choose
to (something like):
c:out value=${someBean.someProperty == someValue ? option1 : option2}
/
It would be rather handy for an obscure use am I putting the EL to work
on.
TIA,
Jon
-
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: Unable to load class
Try with the following taglib directives instead: %@ taglib prefix=c uri=http://java.sun.com/jsp/jstl/core; % %@ taglib prefix=sql uri=http://java.sun.com/jsp/jstl/sql; % -- Pierre Mike Steigerwald wrote: Hi, all, I'm new to taglibs, and relatively new to java, so maybe this really isn't the stumper it seems to me. I'd appreciate any suggestions. I have started with, IMHO, a simple sql jsp. However, I'm having a devil of a time correctly implementing the sql taglibs. My current quandary is this compiler error: Unable to load class org.apache.taglibs.standard.tag.el.sql.SetDataSourceTag This is the offending jsp code: %@ taglib uri=/web-inf/tld/c.tld prefix=c % %@ taglib uri=/web-inf/tld/sql.tld prefix=sql % sql:setDataSource var=productDS url=jdbc:odbc:agdb driver=sun.jdbc.odbc.JdbcOdbcDriver / I've looked at the sql.tld file. It looks complete and uncorrupted, but I'm no expert. Would that be a likely source of error? Thanks - 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: breaking out of c:forEach
Carole,
You may want to check the archive of this list at
http://archives.apache.org/eyebrowse/SummarizeList?listId=44
Do a search on break and you'll get a lot of information
on the topic.
-- Pierre
Carole Mah wrote:
How would one break out of a c:forEach?
For example, in a regular programming language, you might do this
kind of thing:
for (int i=0; i someMaxValue; i++) {
if (someCondition) {
doSomething();
// So we don't have to bother going through rest of loop:
i = someMaxValue;
}
}
How would this be done in a c:forEach ??
Thanks.
-carole
--
Carole E. Mah
[EMAIL PROTECTED]
Senior Programmer/Analyst
Brown University Computing Information Services
Academic Technology Services
Scholarly Technology Group
http://www.stg.brown.edu/
-
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: why the jstl didn't work :(
If you've downloaded the nightly recently, the URI for core (and all other taglibs) in JSTL 1.1 has changed to: http://java.sun.com/jsp/jstl/core http://java.sun.com/jsp/jstl/fmt ... Sorry for the inconvenience... -- Pierre joni santoso wrote: Hi, I have downloaded jakartataglib and tried to deploy it on tomcat 4118 and 4124. i even have tried running the examples. but still no avail. can anyone tell me :(. this is the error message: I have added the taglib in web.xml like this : !-- taglib taglib-urihttp://java.sun.com/jstl-el/core/taglib-uri taglib-location/WEB-INF/c.tld/taglib-location /taglib taglib taglib-urihttp://java.sun.com/jstl/core/taglib-uri taglib-location/WEB-INF/c-1_0.tld/taglib-location /taglib -- HTTP Status 500 - type Exception report message description The server encountered an internal error () that prevented it from fulfilling this request. exception org.apache.jasper.JasperException: This absolute uri (http://java.sun.com/jstl-el/core) cannot be resolved in either web.xml or the jar files deployed with this application at org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:105) at org.apache.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java:430) at org.apache.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java:154) at org.apache.jasper.compiler.TagLibraryInfoImpl.(TagLibraryInfoImpl.java:159) at org.apache.jasper.compiler.Parser.parseTaglibDirective(Parser.java:354) at org.apache.jasper.compiler.Parser.parseDirective(Parser.java:381) at org.apache.jasper.compiler.Parser.parseElements(Parser.java:795) at org.apache.jasper.compiler.Parser.parse(Parser.java:122) at org.apache.jasper.compiler.ParserController.parse(ParserController.java:199) at org.apache.jasper.compiler.ParserController.parse(ParserController.java:153) at org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:227) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:369) at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:473) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:190) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:295) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:241) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:247) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:256) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2415) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:171) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:172) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:174) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:223) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:594) at
Re: JSTL error
mailinglist wrote: Hi, I installed Sun jwsdp-1_1 and copied jstl-examples.war in Tomcat 4.1.18 webapps (not the one shipped with Sun jwsdp) but I get an error when I try the examples: HTTP 500 javax.servlet.ServletException: Cannot inherit from final class at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:249) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Application FilterChain.java:247) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCh ain.java:193) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.ja va:260) etc... Is there a problem with jstl-1.0.3 and Tomcat 4.1.x ? No. It is xerces that's causing the problem. Simply replace xercesImpl.jar located in tomcat-4.1.18/common/endorsed with xercesImpl.jar found in jwsdp-1.1/jaxp-1.2.2/lib/endorsed. Everything should then be back to normal. -- Pierre - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tag libraries that use ExpressionEvaluator depend on Jakartaimplementation
David M. Karr wrote: This is probably obvious, but it is the case that any tag libraries that use the ExpressionEvaluator class in the Jakarta JSTL implementation are actually dependent on the Jakarta implementation, as opposed to the specification, correct? Yes this is correct, as mentioned also by Tim. Since only the JSP api is described in the specification, and not the Java api, Sorry, I don't quite get the distinction you're making here. then another JSTL implementation could use a completely different class. I'm not complaining, I just want to make sure I'm clear on that point. If you are talking JSTL 1.0 URIs, then this is correct. With JSTL 1.1 URIs, the EL is provided by the JSP container and an API is exposed in the JSP 2.0 spec for whoever wants direct access. -- Pierre - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Date value now
David Goodenough wrote:
In an early version of JSTL (one prior to proper release) I seem to recall
that leaving the value out of a fmt:formatDate tag defaulted to using the
value of now as the time/date to format. This seems to have vanished
from the released version. Firstly why the change, and secondly what is
the approved method, preferably without resorting to Java, of formatting
the current time. The best I have found is to jsp:useBean with class
java.util.Date, which will default to now, and format that.
Thanks in advance
David
Can't remember exactly why it was dropped, but I'm sure there was
a good reason :-). We had then added the following text
in the spec (Section 9.9) to make sure questions like yours would
be answered in the spec itself:
In order to format the current date and time, a jsp:useBean
action may be used as follows:
jsp:useBean id=now class=java.util.Date /
fmt:formatDate value=${now} /
-- Pierre
-
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: fmt:parseNumber
Eddie Barna wrote:
I thought it would be fun to use JSTL for some form validation instead of Javascript. I am trying to make sure a user only enters numbers in a field called AcctNum. Also i decided to use fmt:parseNumber / to test my field. Here's the code:
c:catch var=parsingError
fmt:parseNumber var=Gotcha value=${param.AcctNum}/
/c:catch
c:if test=${Gotcha != param.AcctNum} var=noMatch/
Now here's where i run into problems. if i input a string followed by numbers such as iu789 then my catch statement catches the error and stores the following statement in in my variable:
javax.servlet.jsp.JspException: In lt;parseNumbergt;, value attribute can not be parsed: iu789
This good. Thats what i am trying to do.
Now if i input something like this: 45678uy78 or number followed by a string such as this: 89087yht then the whole page craps out on me and i get this error from the server:
org.apache.jasper.JasperException: javax.servlet.jsp.JspException: An error occurred while evaluating custom action attribute test with value ${Gotcha == param.AcctNum}: An exception occured trying to convert String 45678uy78 to type java.lang.Long (null) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:248)
My understanding is that my catch statement is supposed to catch this also but it doesn't. Am I missing something here guys? Please be gentle since i am a novice. TIA
Here is what happens:
- The parsing of 45678uy78 yields the number 45678.
I agree this is weird, but that's the behavior of NumberFormat.parse().
[Sorry haven't had the time to dig further in the javadocs to explain why it
would not
throw an exception if you have digits followed by non-digits, but that's
the way it is if no pattern is specified :-(]
- The expression 45678 != 45678uy78 triggers the conversion of
45678uy78 to a Long and fails (see section A.3.6.2 of the spec).
You'd therefore want to insert your conditional tag inside the c:catch.
c:catch var=parsingError
fmt:parseNumber var=Gotcha value=${param.AcctNum}/
c:if test=${Gotcha != param.AcctNum} var=noMatch/
/c:catch
c:if test=!empty parsingError
invalid input
...
/c:if
!-- if I get here, input is valid --
...
-- Pierre
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem with empty key word on a collection.
Henri Yandell wrote: On Thu, 13 Feb 2003, Schnitzer, Jeff wrote: From: Shawn Bayern [mailto:[EMAIL PROTECTED]] Why not implement the empty keyword on all collections? The method isEmpty is available in the Collection interface. Was there some sort of argument against that when the spec was defined? I believe so; I don't remember the details of the debate, but I think the justification is that the EL doesn't deal with Collections in general in any other situation. ?? I'm pretty sure I can do a forEach across a Collection. This seems entirely inane. Would someone patch the Jakarta implementation to allow the empty operator on Collection? We don't use specifications, we use software. For Tomcat, I imagine the answer would be a flat no, but Jeff has a point here. Standard Taglib isn't the RI anymore is it? Doesn't that come from Sun? For Tomcat, I imagine the answer would be a flat no, but Jeff has a point here. Standard Taglib isn't the RI anymore is it? Doesn't that come from Sun? Correct. 'standard' is the basis for the RI shipped by Sun. So can't Standard Taglib add patches like this that are natural and right? What is important to note is that 'standard' also ships as an implementation of the JSTL specification. Because of this, 'standard' must therefore pass the TCK. The change that Jeff is proposing, although of interest, would unfortunately break compatibility with the spec. (sorry guys, but the Expert Group ain't perfect) Given that the EL is now moving from the JSTL spec to the JSP spec, the best way to handle this would be for Jeff to submit a comment to the JSP spec comments alias at [EMAIL PROTECTED] Hope this helps, -- Pierre - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: accessing static fields/methods from a static class using jstlel
Henri, Not being able to use static properties is a bit crappy. Who do we go kick to get them? JSTL JSR? Shawn? JSP JSR? As of JSP 2.0/JSTL 1.1, the Expression Language is owned by the JSP spec. The above issue as well as support for method invocation in the EL has been the center of hot debates in JSR-152 (JSP 2.0). The tradeoff for JSP 2.0 has been to extend the EL to support declared functions. See JSP 2.0 Proposed Final Draft (http://jcp.org/aboutJava/communityprocess/first/jsr152/index.html) for more details, and send your comments to [EMAIL PROTECTED] if you'd like to voice your opinion. -- Pierre - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: c:if and boolean value
Try the following:
c:if test=${mapservice.running}
[What Timothy suggested would also work, but there is no need
to test against true, since you already have a boolean expression
for your test.]
-- Pierre
Timothy Kettering wrote:
offhand, id say you should be doing this. (enclose the entire
evaluation in the curly braces)
c:if test=${mapservice.running == true}
On Wednesday, February 5, 2003, at 08:23 PM, John C Cartwright wrote:
Hello All,
I have a isRunning() method in my bean that returns a boolean. I'm
try to test against that value with something like the following:
c:if test=${mapservice.running} == true
img src=../images/TransGear.gif width=20 height=20
/c:if
The problem is that even though the bean's getter method is properly
returning the true value (I can print it into the HTML page), the
above conditional always fails. Can someone point out what I'm doing
wrong?
JSTL v.1.2, core library.
Thanks!
-- john
=
John Cartwright
Associate Scientist
Geospatial Data Services Group
CIRES, National Geophysical Data Center/NOAA
(303) 497-6284
[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: Non Java Developers, programmers using JSTL and taglibs
[EMAIL PROTECTED] wrote: Hello- Forgive my comments as they are not technical. Just observations I have made on a few projects over the past couple months. Since there are very few java programmers who are designers, and vice versa - there must be a comfortable zone where designers/developers can integrate their works without battles. I have found that there is little place for a WYSIWYG design team outside of prototyping, this becomes even more evident as applications evolve. In a recent project we migrated JSP 1.1 code and old ratty HTML code to jsp1.2/struts, with XHTML and CSS-P on the client side. I have found that having good designers that write good XHTML code and use CSS have the foundation to understand the MVC approach - After all they are doing the same thing with the style and layout that java developers try to do with the model, view and controller. All the java developers I work with understand the view layer, and all the designers understand how the model and controller fits into their design. I think XHTML helps out a lot. And I have seen it. I sit on both sides of the fence; I do some view design but mostly backend. Some days I am in Jdeveloper some days I am in dreamweaver validating XHTML pages. I have a lot of people like me on my team and it just works. If you are stuck with crummy designers that don't get the backend at all, giving them a set of tags to use won't help the situation. Educating them will. If they don't want to learn, send them back to the marketing department to work on the new web designers business cards. Just because their designers doesn't mean they shouldn't understand the backend, and vice versa. Sorry for the long message. -chris Chris, Actually, it is not long enough, I'd like to hear more :-) Could you give some specifics on how XHTML did help. What are the typical interactions between the designers and the developers? How much back and forth happens between the two groups? Anyone has ownership of the page at the end of the day? Thanks, -- Pierre - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Non Java Developers, programmers using JSTL and taglibs
Renick, Garrel wrote: This is an interesting topic, and people obviously have strong opinions about successes and failures at using this technology within their work environments. My viewpoint is that JSTL provides a nice set of features that most page designers with some programming experience will be able to use, especially if they spend the time to learn about the web application environment (request/response, scope, etc.) and get a good reference like Manning's JSTL in Action. Many work environments need web applications for simple tasks of presenting dynamic data, and JSTL is perfect for that. As the designers become more familiar with the technology, they can move on to more sophisticated projects that use frameworks such as Struts. I think part of the problem with this discussion is the notion that team members fit nicely in roles such as developer, page designer, and graphics artist. Jeez, the original poster even differentiated himself (the 'developer') from programmers and that distinction baffles me. I would guess that few shops have staff that fit so nicely into these roles, but instead there is a blending of disciplines and each staff member has one or more specialties. I have programming experience in other languages and web design experience, but I don't have the entire Java API under my belt (yet). For people like me that constantly deal with the view aspect of a project but also have some programming experience, JSTL offers a nice standards-based middle-ground where I can contribute. Conversely, if I was a pure graphics artist without programming experience, then I would have no interest in learning JSTL, even if it does look like HTML, and you'd be a fool to think that voila!, I could instantly understand the techniques for using JSTL to accomplish some tasks. However, what would be, in your opinion, the best approach in a situation where a company requires a Philippe (graphics-artist/page-designer) to design a dynamic web site that is appealing and easy to use? Something, Mike, the server-side engineer is definitely not qualified to do even though he can crank html very quickly (we're talking usability here ;-) How much of a stretch is it to get Philippe (assuming typical knowledge of JavaScript a designer would have) to use JSTL so he can have full control over the pages of the website? Or is it simply easier to just forget about training Philippe, and have Mike integrate the dynamic portions with the static designs of Philippe, and go back and forth between the two. Is it a tool issue? Just curious... Trying to get as many data points as possible... -- Pierre - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: problems with fmt:setLocale
Before I look more deeply into bug 16751 submitted by Pere that seems to be related to what Alberto and Pablo have been experimenting in the past, could someone translate the important points of the email sent by Pablo on that topic. I'd think that funcionaba correctamente means that it works properly. But I'd need to know if indeed there is a bug to be fixed or not. And if a bug needs to be fixed, a sample JSP page that triggers it would be most welcome. Thanks, -- El Pedro Pablo Benito wrote: Yo lo resolví , cambiando la configuración del tomcat, para q no cacheara las tag-libs, aunque aun así no funcionaba correctamente. Un problema que detecté es que había cierta interacción con otras tag-libs, pq haciendo dos jsp's q sólo tuvieran los tags de fmt, y funcionaba correctamente. Así que lo primero que haría sería probar eso(jsps aislados), y luego intentar arreglar el resto de la aplicación (Haciendo cosas, en principio, sin sentido, como cambiar el orden de importación de los tlds al principio de los jsps..) Suerte Pablo - Original Message - From: Alberto Tomas [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, February 03, 2003 6:40 PM Subject: problems with fmt:setLocale Hy all, I have the same problem that Pablo Benito has: http://www.mail-archive.com/taglibs-user@jakarta.apache.org/msg04074.html; I'm using jboss-3.0.3_tomcat-4.1.12. Now I'm using the nightly build. How can I solve this problem? Thank you in advance, Alberto. _ - 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: FW: BUg in forEach tag of JSTL
Vishal, Many people in this community are willing to help you, but there are a few things you should know that will make it easier to get the support you are looking for. 1. Send questions to the proper alias Please post your questions/comments related to jakarta-taglibs to [EMAIL PROTECTED] 2. Provide pertinent information - Clear description of the problem - What specific error do you get - What version of the taglib and what platform - Sample code that shows the problem Also, in the case of 'standard', it is always a good idea to first try to run the standard-examples webapp that ships with the release. -- Pierre Pier Fumagalli wrote: Not acked. Pier -- Forwarded Message From: [EMAIL PROTECTED] Date: Thu, 23 Jan 2003 12:36:05 +0530 To: [EMAIL PROTECTED] [EMAIL PROTECTED] Subject: BUg in forEach tag of JSTL Hi, i am using Standard1.0 library in my project. i have included both (jstl.jar standard.jar) jar files in my applications WEB-INF directory.. but when i use 'forEach' tag in myh jsp.. it gives compile time error.. Also when i use 'Out' tag..it is not showing any output on the screen .. (its not showing any compiletime/ runtime error) Please let me know if there is any solution to these bugs.ASAP regards, vishal -- End of Forwarded Message -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: fmt:message texts does not change when changing browser language?
Fredrik Westermarck wrote: Johan Ekman wrote: However this does not seem a plausible solution. Has anyone else encountered this problem ? If you are using Tomcat 4.1.x disable the tagpooling in $CATALINA_HOME/conf/web.xml by setting enablePooling to false for the JspServlet. ... or download the nightly. Bugs related to tag pooling have been fixed in 'standard' since 1.0.2. Shawn will be releasing 1.0.3 shortly. -- Pierre -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: problems with fmt:setLocale
Pablo, Paul,
There were a few bugs related to tag-reuse and the formatting
tags. I'd suggest using the nightly build and see if the problems
persist.
Please do let us know whatever the outcome is; we really want
to fix these problems.
Thanks,
-- Pierre
Paul Campbell wrote:
Hola Pablo,
I am not certain that I understand completly.
This is what I do to take the language that the browser
has and use that for the user.
c:if test=${param.language == 'en'}
fmt:setLocale value=en scope=page /
/c:if
c:if test=${param.language == 'es'}
fmt:setLocale value=es scope=page /
/c:if
fmt:setBundle basename=pages var=pagesBundle /
fmt:setBundle basename=sitetext scope=page /
I had one problem.
I needed to set enablePooling=false in conf/web.xml
for the jsp servlet.
When I took the default, the lang first used by the
browser was the only language it would display.
Let me know if you still have problems or if I misunderstood
your question.
At 09:26 PM 12/21/2002 +0100, you wrote:
Hi all:
I'm trying to i18n a web app using jstl and jakarta tomcat 4.1.12.
I'm trying to keep the same language for all a user session,
existing the possibility that the user change the language calling to
index.jsp?lang=es.
This is the index.jsp file (called with index.jsp?lang=en to change to
English language...
-
%@ taglib prefix=fmt uri=http://java.sun.com/jstl/fmt; %
%@ taglib prefix=c uri=http://java.sun.com/jstl/core; %
..
...
c:set var=locale value=${param.lang} /
fmt:setLocale value=${locale} scope=session/
fmt:setBundle basename=com.pablo.mybundle scope=session/
fmt:message key=configActual /
..
..
The rest of the files are supossed to share the Locale and Bundle, so
jsp's might look like this:
%@ taglib prefix=fmt uri=http://java.sun.com/jstl/fmt; %
..
fmt:message key=myKey /
..
The problem is that the language doesn't change. It just changes the first
time is called:
i.e: If the first call is index.jsp?lang=fr, the language will be french
for all the time the session lasts.
I've take a look at previous posts and changed the conf/web.xml
enablePooling to false, but nothings change.
Have any of you heard or experienced similar problems?
Best regards, and Merry Christmas!
PaBLo!
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Dynamically generating the xpath for x:out
See section 11.1.2 of the spec, and try the following:
x:out select=$doc//blog/blog-entry[@id=$param:article]/@title/
Remember that in a 'select' attribute, the language used is XPath,
not the EL.
-- Pierre
Mike Bowler wrote:
Jakarta Standard Taglib version 1.0.2
I have the following statement which works fine on the xml document that
I've loaded.
x:out select=$doc//blog/blog-entry[@id = 'removespaces']/@title/
The problem is that I need to dynamicallly generate this xpath
statement. When I hard code it as above, it works fine. When I try to
generate it dynamically, I never get any matches. I've tried a variety
of different syntax's but basically what I would expect to do is the
following
x:out select=$doc//blog/blog-entry[@id = '${param.article}']/@title/
I'm trying to take the value from ${param.article} and put it in where
the string removespaces was in the first xpath. I've been reading
through the JSTL spec but I can't find the answer to this one.
Any thoughts?
--
Mike Bowler
Principal, Gargoyle Software Inc.
Voice: (416) 822-0973 | Email : [EMAIL PROTECTED]
Fax : (416) 822-0975 | Website: http://www.GargoyleSoftware.com
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: JSTL
The JSP Standard Tag Library was first called JSPTL when it was in Early Access. The name was later changed to be JSTL. This is the same JSP spec. (see JSR-052 at www.jcp.org, or see http://java.sun.com/products/jsp/jstl) -- Pierre Christian Avril wrote: In my question , there is no confusion JSTL and JSP TL use both the tags ( c...core, xml, database ) But why two names for the same Tag Library ? Christian Avril a écrit : Hi , Can You tell me what's the difference between JSTL andJSP Standard Tag Library I Just use Struts and I use the tag ( html , logic ...bean ) I see information about JSTL . ( c for core ...etc ) But , please what's difference with JSP Tag Library. Let's see... perhaps JSTL is for Apache jakarta and JSP TL for Sun ? or JSP Standard Tag Library when JSTL ( core, xml,database ) is not enough ? I know, when we don't know , It's confused Thank's Chris -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: fmt:setLocale Revisited
John Sessler wrote:
Hello All,
I am experiencing the same problem described by someone else in Oct.
however, the solutions suggested do not work for me. When compiling a page
with the fmt:setLocale tag the compiler reports the following error
message:
error:null(-1,-1) h3jsp.error.tlv.invalid.page/h3p8: Illegal scope
attribute without var in fmt:setLocale tag.
Hummm... This error says that a dangling scope is not allowed for
setLocale (i.e. having scope without var). However, I just checked the
code for standard-1.0.2 and it *is* allowed (as the spec says).
Could you try the following simple JSP and tell us if you get the error
or not.
%@ taglib prefix=fmt uri=http://java.sun.com/jstl/fmt; %
fmt:setLocale value=fr scope=request/
It works!
-- Pierre
Environment: jdk1.4.0_01-b03, Jakarta-Tomcat 4.1.12-LE-jdk1.4,
jakarta-taglibs-standard-1.0.2 (JSTL), jakarta-struts-1.0.2, JBuilder6,
Win2k
The jsp is a minor variation of the struts example program (index.jsp). The
minor variation is from
http://developer.java.sun.com/developer/technicalArticles/Intl/MultilingualJ
SP/ (watch out for the typos in the code) and allows the user to set the
language for the web page. Here is the relevant part of jsp page:
%@ page contentType=text/html;charset=UTF-8 language=java %
%@ taglib uri=/WEB-INF/struts-bean.tld prefix=bean %
%@ taglib uri=/WEB-INF/struts-html.tld prefix=html %
%@ taglib uri=/WEB-INF/struts-logic.tld prefix=logic %
%@ taglib uri=/WEB-INF/jstl-core.tld prefix=c %
%@ taglib uri=/WEB-INF/jstl-fmt.tld prefix=fmt %
html:html locale=true
head
titlebean:message key=index.title//title
html:base/
/head
body bgcolor=white
logic:notPresent name=database scope=application
font color=red
ERROR: User database not loaded -- check servlet container logs
for error messages.
/font
hr
/logic:notPresent
logic:notPresent name=org.apache.struts.action.MESSAGE
scope=application
font color=red
ERROR: Application resources not loaded -- check servlet container
logs for error messages.
/font
/logic:notPresent
h3bean:message key=index.heading//h3
%-- Interpret user's locale choice --%
c:if test=${param['locale'] != null}
fmt:setLocale value=${param['locale']} scope=session /
/c:if
%-- Offer locale choice to user --%
a href=index.jsp?locale=enEnglish/a -
a href=index.jsp?locale=esCastellano/a -
a href=index.jsp?locale=frFrancais/a
Here is the relevant portion of web-xml (struts taglibs not shown):
taglib
taglib-uri/WEB-INF/jstl-core.tld/taglib-uri
taglib-location/WEB-INF/c.tld/taglib-location
/taglib
taglib
taglib-uri/WEB-INF/jstl-fmt.tld/taglib-uri
taglib-location/WEB-INF/fmt.tld/taglib-location
/taglib
The page works (displays internationalized content) using bean:message but
I
want to use fmt:message because the latter accepts objects from the
expression language as the value for the key while bean:message accepts
only
hardcoded strings, as I understand.
I have tried the suggestion of using http://java.sun.com/jstl/fmt in the
taglib directive but the compiler reports a NullPointerException (no
indication of where). Curiously, my environment disallows running the page
with the Illegal scope attribute without var in fmt:setLocale tag error
but does allow the page to run with the NullPointerException. Even though
the page runs after the NullPointerException messages are not
internationalized.
Both reported errors are exclusive to the statement fmt:setLocale
value=${param['locale']} scope=session /. If removed the page compiles
and runs, without the user selected locale of course.
I have tried many variations of the taglib directive but this doesn't solve
the problem. I have checked the libraries available during compilation but
have yet to discover a missing library (obviously).
Can someone:
Point out a simple but complete working example (other than the reference
at Sun already mentioned) which uses the fmt:setLocale tag?
Give me some insight on why the setLocale tag looks for a var attribute
when var is not an acceptable attribute for the setLocale tag?
Suggest something else to to try?
Thank you in advance,
John
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Transactions with dbTags
Xose, You might want to check the 'sql' tags in JSTL. They provide transaction support. JSTL is implemented in the 'standard' project. See http://jakarta.apache.org/taglibs/doc/standard-doc/intro.html -- Pierre Xose Ramon Sousa Vazquez wrote: I am working with dbTags and PostgreSQL. I'd like to perform TRANSACTIONS with dbTags. How can i do it?. I have tried to send a several queries like BEGIN insert.. COMMENT, but it performs an error before the first insert. Is it posible to make a transaction using only dbtags sql:statement id=a con=b/sql:statemenmt? Thanks in advance Xosé Ramón Sousa Vázquez Optare Solutions S.L. [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Taglibs to provide an abstraction for mobile device guis
Are there any taglibs out there that provide an abstraction layer for PDA device displays? An example of such would be the Microsoft ASP.NET mobile controls. The controls will properly render the gui widgets on about 200 devices ... JavaServer Faces, currently being defined in JSR-127, should help with this. See http://jcp.org/en/jsr/detail?id=127 -- Pierre -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
ApacheCon US 2002
I will be at ApacheCon next week in Las Vegas. Besides providing great technical sessions and bofs, ApacheCon is a great opportunity to meet members of our community. So if you are going to be there, please let me know. I'd like to organize a small gathering if there is interest within the taglibs folks that will attend. Thanks, -- Pierre -- To unsubscribe, e-mail: mailto:taglibs-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:taglibs-user-help;jakarta.apache.org
Re: Tag for uploading
Stefan wrote: ... Is there a tag for uploading of files in JSTL? No. You may want to check the html:file tag in struts. -- Pierre -- To unsubscribe, e-mail: mailto:taglibs-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:taglibs-user-help;jakarta.apache.org
Re: sql, choose and scope
I suspect the body of the when clause is not executed
because its condition evaluates to false.
You should print the value of param.sqlRequest prior
to the c:choose to make sure it has the value 1.
-- Pierre
Lorenzo Sicilia wrote:
A problem about scope:
my script
c:choose
c:when test=${param.sqlRequest == 1}
sql:query var=flashRecordSet
SELECT ID_news,data,
titolo_it as titolo,
abstract_it as abstract,
testo_it as testo
FROM tb_news
/sql:query
/c:when
/c:choose
Result rs = (Result)pageContext.findAttribute(flashRecordSet);
I can't find flashRecordSet. If SQL tag is out the tags Choose and When
all work fine.
Some one can explain me why? I need just the path to get flashRecordSet
thanks Lorenzo Sicilia
--
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: JSTL and sort ordering of the item in the Result object.
Stefan wrote:
My previous email was a little too vague so I will try again.
I am populating a JSTL Result object with a cached Rowset derived from a bean method
like so:
Result r = ResultSupport.toResult(dataBase.getAllUsers());
pageContext.setAttribute(r, r);
I then loop though the records with a forEach tag:
c:forEach items=${row} var=value
tdc:out value=${value}/nbsp;/td
/c:forEach
Is there a way (within the Result object) to set the order of the records displayed
by the forEach tag? I basically like to imitate an SQL ' order by ' without having to
go back to the database.
No. See below for a reply that Shawn sent a few months
ago on a similar question.
-- Pierre
Original Message
Subject: Re: jstl sort
Date: Tue, 6 Aug 2002 08:46:45 -0400 (EDT)
From: Shawn Bayern [EMAIL PROTECTED]
Reply-To: Tag Libraries Users List [EMAIL PROTECTED]
To: Tag Libraries Users List [EMAIL PROTECTED]
On Tue, 6 Aug 2002, Þorgils Völundarson wrote:
Is it possible to sort information from jstl x:forEach?
JSTL's x:forEach tag always uses the order of the node-set returned from
the XPath 'select' attribute. JSTL's c:forEach always returns the items
in collection order. In JSTL 1.0, there isn't a way to modify this
behavior. The best thing to do is to sort the collection or node-set
outside of your JSP page (e.g., in a servlet) and then expose the sorted
collection to your page.
--
Shawn Bayern
JSTL in Action http://www.jstlbook.com
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Capturing Outputted Content
Stacy Young wrote: Hi All ! I'm a newbie! Would like to know if there's a tag that can capture any JSP generated content within it's borders and make a variable available with the result of this content for use somewhere else on the page ?! One should be available soon (within 3-4 weeks) in the JSPTL taglib. We are currently designing a set of IO and transformation tags that should provide this kind of capability. For example: iot:in url=/jsp/myPage.jsp var=myPage/ ... x:aTag in=$myPage .../ -- Pierre [Disclaimer: JSPTL is work in progress...]
Re: hi
There is an excellent book dedicated to Tag Libraries that just came out: JSP Tag Libraries Gal Shachor, Adam Chace, Magnus Rydin May 2001, Softbound, 656 pages ISBN 193011009X You can get the details at http://www.manning.com/shachor/index.html -- Pierre Lou Caudell wrote: Your right, most are weak in this area, and inaccurate too. Try Web Development with Java Server Pages by Duane K. Fields and Mark A. Kolb. Lou Caudell inflightonline.com -Original Message- From: Vikramjit Singh [mailto:[EMAIL PROTECTED]] Sent: Friday, June 15, 2001 12:04 AM To: '[EMAIL PROTECTED]' Subject: RE: hi thanks Lou for your help. but i could not find any jsp books in which Tag Libraries are given in detail. if u could suggest them then it would be of great help. and thanks for ur help. that article is quite informative. vikramjit singh Systems engg. www.gtl.co.in -Original Message- From: Lou Caudell [SMTP:[EMAIL PROTECTED]] Sent: Thursday, June 14, 2001 1:07 PM To: [EMAIL PROTECTED] Subject: RE: hi Well there are lots of books out there. You will probably need them to learn about writing tag handlers. But to put it all simply read Reuven Lerner's article in Linux Journal called Custom JSP Actions. I believe it's the Jun. or July 01 edition. - Lou Caudell inflightonline.com -Original Message- From: Vikramjit Singh [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 14, 2001 3:18 AM To: [EMAIL PROTECTED] Subject: hi hi everybody, please could anybody help me in how to use and deploy jakarta-taglibs. in the documentation it is not given in so detail. if anybody could help me it would be really helpful. since i have to implement it in a project. vikram
Re: misc JDBC tags notes (was: Re: colName should be case insensitive?)
Pierre, how is the dashboard proposal coming? Slow. Thought I'd have some time last week, but focus is really on JSR-052 (so standard taglibs come out one day :-)). Can't promise anything until JavaOne :-( -- Pierre
Re: Parameters in include tag
Manuel Alzola wrote:
Hello. Im using the include tag to put the output of a servlet into a jsp
page. It works fine but I also need to put some parameters in the request. Is
there a nested tag to let me do this? Is there any other way to accomplish it?
You may use:
jsp:include page=urlSpec flush="true"
{ jsp:param / }*
/jsp:include
-- Pierre
Re: [PATCH] building too hard!
Jeff Turner wrote:
How about using the preset CLASSPATH as a fallback, to be relied on only after
printing a dire warning? Eg, one could have the following system (taking Ant as
an example):
if $ANT_JAR set `$ANT_JAR` exists:
use it
elseif $ANT_HOME set `$ANT_HOME/lib/ant.jar` exists:
use $ANT_HOME/lib/ant.jar
else:
print dire warning
if sensible default (../jakarta-ant/lib/ant.jar) exists:
append it to user-specified classpath
else:
print even direr warning
use user-specified classpath and hope they included ant.jar
This makes clear to the user that setting an env variable is preferable, but
doesn't *force* them to. In truth, this involves just 3 additions to the
current system:
I see your point that some developers might be annoyed with having to set
these env variables. However I bet the majority of them would
eventually set these environment variables just to get rid of the
*even direr warning* that would show up everytime they build :-)
1) Introduces a new variable, $package_JAR (eg $ANT_JAR). Why bother? Because
notice that how we get from the more general $project_HOME to the jar is
hardcoded ("/lib/"), and therefore possibly wrong (eg, between source and binary
distros).
2) Prints a warning each time an expectation is violated.
3) Checks whether jars exist before using them (using "exists" keyword for
.bat, and "-e" test in .sh)
Does this seem sensible?
Definitely.
Anyway, I'll modify build.(sh|bat) again to reflect the above scheme, and post
here so people can review the real thing.
We should also probably movfe to ANT 1.3 now that it is released, so that we
can make use of its ability to get environment variables directly out of the
environment, and then we can do away with the build.sh and build.bat files
-- and use ANT directly!
No build scripts would be *very* cool :)
++1.
And from the latest posting from Tim, it looks like this is doable.
Tim Dawson wrote:
I'd be happy to do the revisions to the build.xml files, but
I'll have to mail it to someone with checkin capability. I'd probably update
one and send it out to see if people agreed with the direction.
This would be awesome. I'll be happy to review (as many others I'm sure).
Please post to the list.
how hard would it be on the community to do the upgrade? everybody would
have to upgrade or they woudln't be able to build.
We could coordinate this as follows:
- Agree on a new build standard (following discussions on build.xml
to be submitted by Tim)
- Assign a coordinator for the new build procedure
(if Tim is interested, we could vote him as a committer. If no one
else volunteers, I could do it)
- have each taglib owner update their build.xml locally
(coordinator and other committers could pickup the ones that won't
be done by their owners)
- have all build.xml sent to the coordinator by a specific date
- coordinator tests the full build procedure and makes required changes
- coordinator commits to the tree.
[Or if coordinator does not mind, he could handle all modifications to the
taglibs himself]
Looking forward to the new build.xml!
-- Pierre
Re: Is it legal to have multiple taglib setter methods for the same property
Alex,
Until the expert group rules on this, one workaround (that will always work)
is to simply do the following (assuming a property of type Object):
instead of:
mytags:foo bar="abc"/
use:
mytags:foo bar='%="abc"%'/
Another way is to define a PropertyEditor associated with your
property of type Object.
As Craig mentioned, this problem has been the subject of numerous
discussions. Here are some pointers that may help you and others
understand the issue.
http://www.mail-archive.com/tomcat-dev@jakarta.apache.org/msg00732.html
http://www.mail-archive.com/tomcat-dev@jakarta.apache.org/msg01323.html
http://www.mail-archive.com/tomcat-dev@jakarta.apache.org/msg01328.html
-- Pierre
"Craig R. McClanahan" wrote:
Alex Tang wrote:
Thanks for the quick reply Craig.
A followup question. In tomcat 3.1, I was able to do
public setIndex ( Object o )
If this is legal, I can do my own internal checking to see if the object "o" is a
String or an
int. However in Tomcat 4.0, I get an error when I try to do this. I saw some
talk about this
on the tomcat archives, however it wasn't clear whether this is an error on my
side or an error
in tomcat.
This has been the subject of no small discussion on the expert group for JSP 1.2. A
final decision
is still pending AFAIK, at which time Tomcat 4.0 will change if it needs to.
Thanks again.
...alex...
Craig
"Craig R. McClanahan" wrote:
IIRC, having two setters with different argument types violates the JavaBeans
specification. In addition, it seems to cause the Java reflection APIs to think
that there
is no setter method at all, so you will get complaints about a read-only
property from any
JSP implementation that uses this technique.
Craig McClanahan
Alex Tang wrote:
Hi folks. (My apologies for crossposting, I wasn't sure if this is a
taglib question or a tomcat question/problem)
I'm writing a taglib using the JSP 1.1 spec (currently Tomcat 3.x). I'm
having a problem with a property "set" method.
I have a taglib tag which takes one parameter: "index". This index can
be either the string "all" or a number representing which CLE object to
show.
I have the following defined in my tld file:
tag
namedisplayCLE/name
tagclasscom.funkware.DisplayCLETag/tagclass
teiclasscom.funkware.DisplayCLEExtraInfo/teiclass
infoDisplay a CLE/info
attribute
nameindex/name
requiredtrue/required
rtexprvaluetrue/rtexprvalue
/attribute
/tag
In my "DisplayCLETag.java" file, I have the following:
/**
* !-- setIndex--
*
*Called when the taglib encounters an int for the index field...
*This form takes an int which happens when a jsp expression is
*evaluated on the right side of the "index=".
*
* @param nIndex
*The index
*/
public void setIndex ( int nIndex ) {
m_nIndex = nIndex;
}
/**
* !-- setIndex--
*
*Called when the taglib encounters the "index" parameter. This
*form takes an object. We try to convert and Integer and a
*String. Anything else we barf on.
*
* @param o
*An object which we'll try to convert.
*/
public void setIndex ( String s ) {
if ( SHOWELEMENT_ALL_STRING.equalsIgnoreCase ( s ) ) {
m_nIndex = SHOWELEMENT_ALL;
return;
}
try {
m_nIndex = Integer.parseInt ( s );
} catch ( NumberFormatException e ) {
Dispatcher.log ( Log.NOTICE, "DisplayListElementTag.setElement",
"The element: '" + s +
"' is invalid, it should be a number" );
m_nIndex = SHOWELEMENT_UNDEF;
}
}
The reason I have two setter methods for Index is that doing:
af:displayCLE index="1"/
is different than
af:displayCLE index="%= i %"/ !-- where i is an int and == 1 --
Is this a legal way of doing this?
I ask because when I run tomcat using the SunJDK1.3, it works fine,
however when I run tomcat with the SunJDK1.3 with Hotspot, it fails with
java.lang.NumberFormatException: all
at java.lang.Integer.parseInt(Integer.java:405)
at java.lang.Integer.(Integer.java:540)
at org.apache.jasper.runtime.JspRuntimeLibrary.convert \
(JspRuntimeLibrary.java:125)
at org.apache.jasper.runtime.JspRuntimeLibrary.introspecthelper \
(JspRuntimeLibrary.java:201)
at
