Re: [JSTL] Java enum constants
Yeah, the topic has come up. It could be done in principle, but
- it won't make it into JSTL 1.0
- there are problems with referring to static members of a class
The JSTL EL just refers to objects, so it's not clear which class in
the object's ancestry hierarchy the static values would come from.
We'd probably need to add a mechanism to refer to a class specifically,
and this would complicate a language that's intended to hide the
details of Java data types for page authors.
Hope that helps,
--
Shawn Bayern
Author, JSP Standard Tag Library http://www.jstlbook.com
(coming this summer from Manning Publications)
On Mon, 15 Apr 2002, Borislav Iordanov wrote:
Hi,
It would be useful if the JSTL expression language supported enum
constants access through the '.' operator. For example:
class A
{
public final static int ENUM_1 = 0;
public final static int ENUM_2 = 1;
public int getType() // returns one of ENUM_1, ENUM_2 etc...
}
and then
c:choose
c:when test=${a.type == a.ENUM_1}
do something
/c:when
c:when test=${a.type == a.ENUM_2}
do something else
/c:when
/c:choose
Could it be done?
Thanks,
Boris
--
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: getRowsCount
The property is now called rowCount:
${result.rowCount}
--
Shawn Bayern
Author, JSP Standard Tag Library http://www.jstlbook.com
(coming this summer from Manning Publications)
On Fri, 12 Apr 2002, Andrea Grittini wrote:
I beg you pardon, (I promise this is my last question) but,
What is the method to know the size of a recordset??
I tried with myrec.getRowsCount and this is the exception trace.
Then I tried with: size, getRowCount, getSize with or without the name of the
recordset, and I got the same result.
Could you help me ??
Thank you
Andrea Grittini
An error occurred while evaluating custom action attribute value with value
${myRec.getRowsCount}: Unable to find a value for getRowsCount in object of class
javax.servlet.jsp.jstl.sql.ResultImpl using operator .
Oops! Your request cannot be completed. The server got the following error.
An error occurred while evaluating custom action attribute value with value
${epNews.getRowsCount}: Unable to find a value for getRowsCount in object of
class javax.servlet.jsp.jstl.sql.ResultImpl using operator .
at org.apache.taglibs.standard.lang.jstl.Evaluator.evaluate(Evaluator.java:206)
at org.apache.taglibs.standard.lang.jstl.Evaluator.evaluate(Evaluator.java:143)
at org.apache.taglibs.standard.lang.jstl.Evaluator.evaluate(Evaluator.java:364)
at
org.apache.taglibs.standard.lang.support.ExpressionEvaluatorManager.evaluate(ExpressionEvaluatorManager.java:109)
at org.apache.taglibs.standard.tag.el.core.ExprTag.doStartTag(ExprTag.java:137)
at
JspPage_actCercaEpNews_jsp_Impl._jspService(JspPage_actCercaEpNews_jsp_Impl.java:4657)
at
com.hp.mwlabs.j2ee.containers.servlet.jsp.AbstractJspPage.service(AbstractJspPage.java:551)
at
com.hp.mwlabs.j2ee.containers.servlet.jsp.JspServlet._service(JspServlet.java:766)
at
com.hp.mwlabs.j2ee.containers.servlet.jsp.JspServlet.service(JspServlet.java:424)
at
com.hp.mwlabs.j2ee.containers.servlet.WebApplicationBean$ServicePrivilegedAction.run(WebApplicationBean.java:4493)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAsPrivileged(Subject.java:558)
at
com.hp.mwlabs.j2ee.containers.servlet.WebApplicationBean.service(WebApplicationBean.java:1977)
at
com.hp.mwlabs.j2ee.containers.servlet.RequestDispatcherImpl.forwardOrInclude(RequestDispatcherImpl.java:405)
at
com.hp.mwlabs.j2ee.containers.servlet.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:134)
at
com.hp.mwlabs.j2ee.containers.servlet.ServletContainerBean.processRequest(ServletContainerBean.java:772)
at
com.hp.mwlabs.as.services.servlet.ServletContainerService.processRequest(ServletContainerService.java:542)
at java.lang.reflect.Method.invoke(Native Method)
at
com.hp.mw.common.util.PolymorphicInvocationHandler.invoke(PolymorphicInvocationHandler.java:223)
at
com.hp.mwlabs.csf.ServiceInvocationHandler.invoke(ServiceInvocationHandler.java:184)
at $Proxy87.processRequest(Unknown Source)
at
com.hp.mwlabs.as.services.listeners.http.HttpRequestHandler.executeImpl(HttpRequestHandler.java:229)
at
com.hp.mw.as.services.listeners.BaseRequestHandler.execute(BaseRequestHandler.java:124)
at com.hp.mwlabs.common.util.ExecutorPool$Entry.execute(ExecutorPool.java:400)
at com.hp.mwlabs.common.util.PeriodicExecutor.run(PeriodicExecutor.java:630)
at java.lang.Thread.run(Thread.java:484)
--
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 / jsp version
On Thu, 11 Apr 2002, Thomas Colin de Verdiere wrote: why is the Jstl jsp1.2 compliant ? Because we figured that making it depend on JSP 1.3 would limit its usefulness, at least before JSP 1.3 comes out. :-) Of course, I assume your question is really, Why not JSP 1.1? It's a good question. There are a few technical answers: - Certain features, and certain behaviors required for consistency, depend on the TryCatchFinally interface in JSP 1.2. - JSP 1.2 supports more efficient iteration, which is a cornerstone feature of JSTL. - Translation-time validation also improves efficiency and knowability of pages. - JSP 1.2 clarifies the lifecycle of tag-handler instances. and probably a few other specific points that I'm forgetting. Beyond the specific technical reasons, JSP 1.2 has been out for about six months now, and we didn't want to limit ourselves to JSP 1.1's set of features and specified behaviors. -- Shawn Bayern Author, JSP Standard Tag Library http://www.jstlbook.com (coming this summer from Manning Publications) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Document on request
On Wed, 10 Apr 2002, De Ridder, Bavo wrote:
If I look at the xtags library, I think to understand that the xml can
come from either a local file, url or the body of the parse tag.
What if I use struts and the XML document is stored in a scope
(request)? How can I do this with xtags? My current solution would be
to patch the parse tag.
If you use JSTL instead of XTags (which indeed influenced the design of
JSTL's XML-manipulation tags), you can retrieve a document from the
request scope using the expression language. For instance, if the
document is stored as a string of XML text, you could write
x:parse var=parsed xmlText=${request.myXmlDocument}/
If the data is stored as a DOM, you can jump right in and point to the
document directly. E.g., --
x:out value=$request:myXmlDocument/root//child[2]/
JSTL is available from the same jakarta.apache.org/taglibs site as XTags.
--
Shawn Bayern
Author, JSP Standard Tag Library http://www.jstlbook.com
(coming this summer from Manning Publications)
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: how can I compare strings in c:if
Glenn,
You're right: thanks for the correction. The scriplet should read
%
String a = foo;
String b = new String(a);
pageContext.setAttribute(a, a);
pageContext.setAttribute(b, b);
%
The point remains: the JSTL expression language's '==' operator leads to
a call to equals() when Strings are being compared. Marba's originally
problem wasn't related to the '==' operator but to the structure of the
sql:query tag's Result objects themselves. (Marba was using an old
Result implementation.)
Thanks again.
--
Shawn Bayern
Author, JSP Standard Tag Library http://www.jstlbook.com
(coming this summer from Manning Publications)
On 10 Apr 2002, Glenn R. Kronschnabl wrote:
Shawn,
Just to clarify - your code snippet is very misleading. The reason
c:if test=${a == b} evaluates to true is because null == null, not
because a == b where a = foo. a b are not in any scope so in the
EL, a b are null - in fact it doesn't matter what you set a or b to.
Changing your example a little:
%
String s1 = string1;
String s2 = string2;
%
s1 = c:out value=${s1}/, s2 = c:out value=${s2}/,
c:if test=${s1 == s2}s1 == s2/c:if
Surprisingly, you'll see s1 == s2 on the output. Of course you'll
also see from the line above that s1 = , s2 = , that is, you're
referencing bogus variables.
Anyways- thought I would clarify for other users out there.
This does point out a danger in the test= stuff, since you reference
bogus variables without error, you may not be actually testing what you
think you're testing.
Let me know if I'm incorrect.
Thanks,
Glenn
On Tue, 2002-04-09 at 09:57, Shawn Bayern wrote:
Are you sure the strings are really identical? For instance, just to be
sure you're using two different Strings with the same value, you can
experiment via the String copy constructor. Doing this demonstrates that
JSTL's '==' operator does work correctly:
%@ taglib prefix=c uri=http://java.sun.com/jstl/ea/core; %
%
String a = foo;
String b = new String(a);
%
c:if test=${a == b}
a indeed equals b
/c:if
Make sure that the two strings in your database don't have different
amounts of whitespace, are indeed of the same case (uppercase, lowecase,
etc.), and so on. I often find it useful to print out values with a
marker (e.g., the ' character) on both sides to make sure I'm not missing
any whitespace.
--
Shawn Bayern
Author, JSP Standard Tag Library http://www.jstlbook.com
(coming this summer from Manning Publications)
On Tue, 9 Apr 2002, marba wrote:
I'm try to compare two string fields in a MySql table row
here's my code that evaluate false even if the strings are identical:
sql:query var=filiali dataSource=${ds}
SELECT * FROM FILIALI_EXT_LOG LEFT JOIN FILIALI_EXT USING (ID)
WHERE FILIALI_EXT_LOG.LASTMODI c:out
value=${user.lastTimeStamp}/
/sql:query
c:forEach var=row items=${filiali.rows}
c:set var=campi value=51/
c:forEach var=i begin=0 end=${campi}
c:if test=${row.columns[i] == row.columns[i]}
evaluates true OK
/c:if
c:if test=${row.columns[i] == row.columns[i+campi]}
evaluates false even if Strings are identical
/c:if
Thank You
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: rtexprvalues in c:if test
Since the JSTL expression language is designed to expose JavaBean
properties, it's probably best to represent constants as such
properties. E.g.,
public class Constants {
private final int BIG_SPENDER = 100;
public int getBigSpender() { return BIG_SPENDER; }
}
will let you use an expression like
${customer.credit constants.bigSpender}
The JSTL expression language doesn't support static member fields in part
beacuse they might clash with JavaBean properties.
Shawn
On 10 Apr 2002, Glenn R. Kronschnabl wrote:
A lot of the jstl examples you see are like:
c:if test=${customer.credit 100}
what I would like to do is to remove the hardcoded '100'.
Ideally, I could have something close to:
%@ page import=my.com.Constants %
c:if test=${customer.credit Constants.BIG_SPENDER}
of course the above does not work. What's the best way to do what I
want? Should I use the c-rt? I know the following works.
c_rt:if test=%= customer.getCredit() Constants.BIG_SPENDER %
But I'm under the mindset to avoid the -rt versions - is that a
misconception?
TIA,
Glenn
--
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: how can I compare strings in c:if
Are you sure the strings are really identical? For instance, just to be
sure you're using two different Strings with the same value, you can
experiment via the String copy constructor. Doing this demonstrates that
JSTL's '==' operator does work correctly:
%@ taglib prefix=c uri=http://java.sun.com/jstl/ea/core; %
%
String a = foo;
String b = new String(a);
%
c:if test=${a == b}
a indeed equals b
/c:if
Make sure that the two strings in your database don't have different
amounts of whitespace, are indeed of the same case (uppercase, lowecase,
etc.), and so on. I often find it useful to print out values with a
marker (e.g., the ' character) on both sides to make sure I'm not missing
any whitespace.
--
Shawn Bayern
Author, JSP Standard Tag Library http://www.jstlbook.com
(coming this summer from Manning Publications)
On Tue, 9 Apr 2002, marba wrote:
I'm try to compare two string fields in a MySql table row
here's my code that evaluate false even if the strings are identical:
sql:query var=filiali dataSource=${ds}
SELECT * FROM FILIALI_EXT_LOG LEFT JOIN FILIALI_EXT USING (ID)
WHERE FILIALI_EXT_LOG.LASTMODI c:out
value=${user.lastTimeStamp}/
/sql:query
c:forEach var=row items=${filiali.rows}
c:set var=campi value=51/
c:forEach var=i begin=0 end=${campi}
c:if test=${row.columns[i] == row.columns[i]}
evaluates true OK
/c:if
c:if test=${row.columns[i] == row.columns[i+campi]}
evaluates false even if Strings are identical
/c:if
Thank You
--
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: how can I compare strings in c:if
On Tue, 9 Apr 2002, marba wrote:
javax.servlet.ServletException: Attempt to apply operator to arguments
of type org.apache.taglibs.standard.tag.common.sql.ColumnImpl and
org.apache.taglibs.standard.tag.common.sql.ColumnImpl
Ah, I believe you're using an older version of the JSTL RI; sorry I didn't
notice that from your syntax. With the current versio, you should just
retrieve the strings directly and compare them. To modify your original
example, I believe you want the following:
sql:query var=filiali dataSource=${ds}
SELECT * FROM FILIALI_EXT_LOG LEFT JOIN FILIALI_EXT USING (ID)
WHERE FILIALI_EXT_LOG.LASTMODI c:out value=${user.lastTimeStamp}/
/sql:query
c:forEach var=row items=${filiali.rowsByIndex}
c:set var=campi value=51/
c:forEach var=i begin=0 end=${campi}
c:if test=${row[i] == row[i+campi]}
...
If you pull down the Beta1 version of JSTL from jakarta.apache.org, I
believe this comparison will work for you. If not, just let us know.
--
Shawn Bayern
Author, JSP Standard Tag Library http://www.jstlbook.com
(coming this summer from Manning Publications)
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: forEach in the rt lib question...
On Mon, 8 Apr 2002, Julia A. Case wrote: I'm trying the following with no luck... c:forEach var=artist items=% playlist.getMP3Artists() % jsp:useBean id=artist type=String / OPTION value=/jsp/view?artist=%= artist %%= artist %/OPTION /c:forEach And what it produces is this OPTION value=/jsp/view?artist=% playlist.getMP3Artists() %% playlist.getMP3Artists() %/OPTION So it's not evalutating the expersion, and I am using the c-rt.tld An attribute value that begins % isn't an rtexprvalue; you're instead passing a string literal. Rtexprvalues must begin with %=. Hope that helps, -- Shawn Bayern Author, JSP Standard Tag Library http://www.jstlbook.com (coming this summer from Manning Publications) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: c:url clunky
On Mon, 8 Apr 2002, Steve Morrison wrote:
I noticed that c:param's in a c:url are added backwards.
So if I have:
c:url var=my_url value=http://example.com/script.jsp;
c:param name=A1/c:param
c:param name=B2/c:param
c:param name=C3/c:param
/c:url
It produces:
http://example.com/script.jsp?C=3amp;B=2amp;A=1
This isn't so good because I have an app that expects things
a certain way.
This, however, is intentional because it's the only way to emulate the
behavior of jsp:include and jsp:param, and this behavior is called for
by the JSTL spec. (Later parameters must supercede earlier parameters,
and the only way to accomplish this is to make sure that later parameters
come first.) The goal is to interoperate well with JSP pages, and this is
(unfortunately) incompatible with applications that care about the order
of their request parameters and apply a different algorithm for their
interpretation than JSP/Servlet does.
Also, I've found the whole c:url stuff to be a bit clunky.
It would be nice if it accepted body content, something like:
c:url var=my_url
%@ include file=my_host.jsf %c:out value=${my_var}/
c:param ... etc.
Right now I need to create some variables, and do
c:url var=my_url value=${my_var}
But this is awkward if I have multiple urls, and the params are the
same, but the paths are different. Especially so, since the only
reason I'm using c:param is that it url encodes strings for me.
I'm not sure I'm clear what you're asking for. You'd want the URL base
path to come from the body in addition to the 'value' attribute? In
principle, this is plausible, although it adds no new functionality --
just a new syntax. Still, I suggest sending that comment to
[EMAIL PROTECTED] so that it gets recorded officially.
Thanks for the comments,
--
Shawn Bayern
Author, JSP Standard Tag Library http://www.jstlbook.com
(coming this summer from Manning Publications)
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Antw: RE: Accessing JSP scoped Variables from within Tags
Is it possible that the target page isn't set up to take query parameters
(versus request parameters passed in a POSTed body)? The isomorphism
between the two isn't universal (although it is indeed common). The
c:import tag, with c:param, only sends query-string parameters and
only uses the HTTP GET method.
What prints out if you write the following --
c:url value=http://intern.masterna.din.de/sixcms/detail.php;
c:param name=id value=${param.id} /
/c:url
If it ends with ?id=X (where X is the right value), then the
problem isn't with your usage of JSTL but with the target page.
Hope that helps,
--
Shawn Bayern
Author, JSP Standard Tag Library http://www.jstlbook.com
(coming this summer from Manning Publications)
On Fri, 5 Apr 2002, TIMO EINSIEDLER-BURGER wrote:
Hey,
well i know cause i tried. Here is the exact jsp-code:
%@ taglib uri=http://java.sun.com/jstl/ea/core; prefix=c %
%
String idd = new String(request.getParameter(id));
out.println(id = + idd);
%
c:import url=http://intern.masterna.din.de/sixcms/detail.php;
c:param name=id value=${param.id} /
/c:import
As you can see i do try (successfully) the regular way to check if the param id
is available. But the page i am trying to import does not get the param id (it is a
Content-Management-System, which tells me that no id was passed to it). What am i
doing wrong ???
Thanks for your help !!!
[EMAIL PROTECTED] 05.04.2002 17.36 Uhr
TIMO == TIMO EINSIEDLER-BURGER [EMAIL PROTECTED] writes:
TIMO Sorry, i maybe did not tell it right ... i want to get a request.param
from the original called jsp and pass it to the imported page ... example below did
not solve that !?!?
TIMO thanks again timo
[EMAIL PROTECTED] 05.04.2002 10.01 Uhr
TIMO I can answer because I've just used it.
TIMO It is
TIMO c:import url=some url
TIMO c:param name=id value=${param.id} /
TIMO /c:import
TIMO I hope this will help you
TIMO Andrea
You know it did not solve that because you tried it? What happened when you
tried it? According to the spec (which is essentially the documentation), this
is exactly how you would do it, if we're understanding what you're asking for.
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: class generation in the exaples
On Wed, 3 Apr 2002, Ken C Eitelman wrote: I downloaded the jstl-beta1 taglibs. I'm trying to deploy the standard-examples.war in order to see how the tags work so that I may apply them. Firstly, the web.xml gets a load error after I try to run it in IBM WebSphere. Should this just be a deploy and run .war, or is there somthing I need to change? The standard-examples.war is indeed meant to work out of the box, although I haven't had the resources yet to be able to test it in multiple commercial containers. If you could post the actual error that you're getting, that would be very useful. Thanks, Secondly, I cant seem to find the startup.init file that was mentioned in some of the source. Without having the proper classes created, I dont think the examples would work very well anyway. I'm not sure I follow; no JSTL source code mentions a 'startup.init' file. -- Shawn Bayern Author, JSP Standard Tag Library http://www.jstlbook.com (coming this summer from Manning Publications) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[New] Cache Taglib
Hi all,
Just wanted to announce the Cache Taglib, now in development at Jakarta
Taglibs.
A large web application provides many opportunities to cache content for
performance. For instance, entire pages could be cached by a filter;
whole chunks of sites could be cached behind a network edge (see
http://www.esi.org). Our Cache Taglib should help build community
experience with using JSP tag libraries to cache fragments of JSP pages
within a Java web application.
The Cache Taglib currently has two tags; they've been designed with JSTL's
principles in mind. Specifically, their goal is to let page authors focus
on presentation and not worry about too many behind-the-scenes details.
(Also, they use the JSTL expression language.) Right now, there are just
two tags: cache:cache and cache:invalidate.
The cache:cache tag lets you wrap a page fragment and indicate that it's
cachable. The tag lets you factor out the dynamic nature of such
fragments, specifying a key that represents the content. For instance,
as the page author, you might know that a large part of your page doesn't
change once a user has logged in; you might therefore use a key of
${user} to indicate that the fragment depends on the 'user' variable.
The cache:invalidate tag lets you explicitly destroy a cache entry or a
whole cache.
Applications can use the Cache Taglib with an unlimited number of caches;
the size and expiration policies of the caches are determined by back-end
code on the assumption that page authors don't frequently need to handle
such details. (There's a utility class, CacheUtil, that lets your code
easily configure the caches.)
Anyway, the tags and documentation are available from
http://jakarta.apache.org/taglibs/doc/cache-doc/intro.html
I'm happy to answer any questions you've got. Again, while the tags
should be usable as presented, this is mainly an experiment to build
experience with taglib-based caching -- so comments would be great!
Thanks.
--
Shawn Bayern
Author, JSP Standard Tag Library http://www.jstlbook.com
(coming this summer from Manning Publications)
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Taglibs and included pages
On Wed, 3 Apr 2002, Bryan P. Glennon wrote: The problem is with the two include files. If I don't repeat the % taglib declarations in the included files, they don't work. It seems to me that once the libs are declared, that declaration should hold for the remainder of the page. I'm sure I'm missing something here, and I'm looking for enlightenment. When you include files with %@ include %, they are incorporated into the source file, and you wouldn't need to re-declare taglibs with %@ taglib %. However, jsp:include lets you include full, stand-alone pages (and other resources). More formally, jsp:include includes a separate translation unit, so the target page will still need its own declarations. -- Shawn Bayern Author, JSP Standard Tag Library http://www.jstlbook.com (coming this summer from Manning Publications) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [standard] sql:param doesn't accept a body
Oh, yes. Sorry -- by CVS head, I mean the latest branch of CVS, which is the one that the nighly builds are drawn from. So the next nightly build implements the fix and should allow you to use sql:param appropriately. (In fact, the problem itself was only introduced in another recent nightly build.) Hope that helps, -- Shawn Bayern Author, JSP Standard Tag Library http://www.jstlbook.com (coming this summer from Manning Publications) On Wed, 3 Apr 2002, Andrea Grittini wrote: Sorry, I didn't understand. Is it the fix already available in the night build? or I have to wait the next release?, or there is a workaround.??? Thanks lot. Andrea Grittini -Original Message- From: Shawn Bayern [] Sent: martedì 2 aprile 2002 19.53 To: Tag Libraries Users List Subject: Re: [standard] sql:param doesn't accept a body Andrea, Thanks for this - this was just a bug. We actually never created a separate TLV for the SQL library, so it was pointing at the core library's validator and thus inheriting its semantics. I've fixed the problem in the current CVS head. Thanks again, -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: JSTL Date Format Question
A variable that prints a string starting with [B is likely a primitive
byte array (byte[]). This means that the MYSQL JDBC driver you're using
is probably returning a byte[] for the column aliased Date when it's
retrieved using ResultSet.getObject(). You could add
c:out value=${row.Date.class} /
to the loop just to be sure.
I'm not sure this is anything the JSTL RI can address. If DBTags works
with exactly the same JDBC driver, it might be that the critical
difference is that the driver returns a usable string when its ResultSet's
getString() method is called; I believe DBTags uses getString() where we
use getObject().
If you let me know specifically what MySQL JDBC driver you're using (a
pointer to its URL would be all I need), I can attempt to trace the
problem further and perhaps resolve the issue with the driver's
maintainers. (Or, of course, my own replication of the problem could show
that it's really our bug.)
Thanks for the report,
--
Shawn Bayern
Author, JSP Standard Tag Library http://www.jstlbook.com
(coming this summer from Manning Publications)
On Mon, 1 Apr 2002, Zvolensky, Thomas J {PDBI~Nutley} wrote:
I have a query that selects records from a datetime column using the JSTL
and MYSQL. When I output the rows to a JSP page I'm getting the following:
Anderau, Eoma BASEL [B@b6421
Andersson, Lisa BASEL [B@5acb2b
[B@5092c0
[B@52883b
[B@6e1775
[B@462631
[B@756456
Andrews, Stella WELWYN[B@e6899
[B@752125
The last column should display a date (dd-mmm-yy).
My JSP code looks like this:
sql:query var=visitor dataSource=${example}
select distinct Authentications.userid,
DATE_FORMAT(Authentications.authtime,'%d,%b,%y') as Date, UserInfo.*,
UserInfo.firstname from Authentications,UserInfo
where (UserInfo.userid=Authentications.userid) and
(Authentications.docbase='eurpr1')
and UserInfo.userid NOT in ('eurpr1','erispre','dmadmin') order by
UserInfo.lastname,Date
/sql:query
.
.
.
!-- Loop through the rows of the query and display in the table --
c:set var=oldname value=/c:set
c:forEach var=row items=${visitor.rows}
c:set var=newname value=${row.lastname}/c:set
!-- New user encountered, print name and location --
c:if test=${newname != oldname}
tr
td align=leftc:out
value=${row.lastname}/,nbsp;c:out value=${row.firstname}//td
td align=leftc:out value=${row.city}//td
td align=leftc:out value=${row.Date}//td
/tr
/c:if
!-- Same user. List visit date only --
c:if test=${newname == oldname}
tr
td align=leftnbsp;/td
td align=leftnbsp;/td
td align=leftc:out value=${row.Date}//td
/tr
/c:if
c:set var=oldname value=${row.lastname}/c:set
/c:forEach
Is a conversion from datetime/date format to text required before the c:out
value=${row.Date}/ tag? If I run the same query and list the records
using th DBTAGS library, the date comes out correct.
TIA
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: JSTL Date Format Question
Okay, I looked at the JDBC driver's code. It returns a byte[] in cases
where the underlying object is java.sql.Types.LONGVARBINARY. For some
reason, then, it looks like MySQL is returning a LONGVARBINARY column for
the one you're labeling Date. This might be because the DATE_FORMAT
function results in a column of MySQL's TEXT type, which may be
translated to JDBC's LONGVARBINARY.
Here's what I would suggest: avoid formatting the date in the query.
That is, let the query ultimately return an actual java.util.Date if the
JDBC driver supports it, or a plain string (parsable with fmt:parseDate)
if it doesn't.
You could try calling getColumnType() to confirm what I've guessed here.
Either way, though, I don't think there's anything we can do in the JSTL
RI to address this MySQL/JDBC issue. Alternatively, the JSTL spec could
be modified to support byte[] more cleanly: for instance, the JSTL EL
could print out a byte[] by converting it to a String using the default
character encoding. This is somewhat ugly, but it might fit nicely with
our other type conversions. I'll raise it to the expert group.
Thanks again for the report,
--
Shawn Bayern
Author, JSP Standard Tag Library http://www.jstlbook.com
(coming this summer from Manning Publications)
On Mon, 1 Apr 2002, Zvolensky, Thomas J {PDBI~Nutley} wrote:
c:out value=${row.Date.class} / produced a blank for the date column.
My JDBC driver is mm.mysql-2.0.11-bin.jar which can be downloaded from
http://prdownloads.sourceforge.net/mmmysql/mm.mysql-2.0.11-you-must-unjar-me
.jar
Regards.
-Original Message-
From: Shawn Bayern [mailto:[EMAIL PROTECTED]]
Sent: Monday, April 01, 2002 12:09 PM
To: Tag Libraries Users List
Subject: Re: JSTL Date Format Question
A variable that prints a string starting with [B is likely a primitive
byte array (byte[]). This means that the MYSQL JDBC driver you're using
is probably returning a byte[] for the column aliased Date when it's
retrieved using ResultSet.getObject(). You could add
c:out value=${row.Date.class} /
to the loop just to be sure.
I'm not sure this is anything the JSTL RI can address. If DBTags works
with exactly the same JDBC driver, it might be that the critical
difference is that the driver returns a usable string when its ResultSet's
getString() method is called; I believe DBTags uses getString() where we
use getObject().
If you let me know specifically what MySQL JDBC driver you're using (a
pointer to its URL would be all I need), I can attempt to trace the
problem further and perhaps resolve the issue with the driver's
maintainers. (Or, of course, my own replication of the problem could show
that it's really our bug.)
Thanks for the report,
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: JSTL Date Format Question
On Mon, 1 Apr 2002, Henri Yandell wrote: Okay, I looked at the JDBC driver's code. It returns a byte[] in cases where the underlying object is java.sql.Types.LONGVARBINARY. For some reason, then, it looks like MySQL is returning a LONGVARBINARY column for the one you're labeling Date. This might be because the DATE_FORMAT function results in a column of MySQL's TEXT type, which may be translated to JDBC's LONGVARBINARY. Am pretty sure this is true. For some reason MySQL TEXT = one of the Binary types in JDBC. It's not normally a big issue as the getString still seems to get the text properly. Interesting. To be more general, JSTL uses getObject() instead of getString(). The idea of converting byte[] to String (using whatever character encoding is available) is growing on me; it's certainly no worse than ResultSet.getString(), and it's also certainly no worse than printing [B@x. MySQL, alas, is common enough that we probably want to at least consider this; in fairness, it's not really a case specific to MySQL, but a more general question of how our EL deals with byte[]. -- Shawn Bayern Author, JSP Standard Tag Library http://www.jstlbook.com (coming this summer from Manning Publications) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: plans for include
On Mon, 1 Apr 2002, peter lin wrote: Does anyone know if there are plans to improve jsp:include or create a new include in jstl? Yes, JSTL introduces c:import, which (as I think I say in my book) you can think of as jsp:include: the next generation. :-) -- Shawn Bayern Author, JSP Standard Tag Library http://www.jstlbook.com (coming this summer from Manning Publications) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: jstl sql dataSource configuration help
On Mon, 1 Apr 2002, James Hazel wrote:
my jsp code is:
sql:query var=stuff dataSource=${dataSource}
SELECT * FROM articles/sql:query
c:out value=Query completed. Rows returned are: /
c:out value=$stuff.getSize() /
I configured the dataSource as a class implementing the javax.sql.DataSource
interface and use it in other places to create the database, but the above
query always returns as if the 'stuff' variable is not initialized: Query
completed. Rows returned are:$stuff.getSize()
I think you're just using the expression incorrectly. You want to write
c:out value=${stuff.size} /
instead.
--
Shawn Bayern
Author, JSP Standard Tag Library http://www.jstlbook.com
(coming this summer from Manning Publications)
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: EL
On Fri, 29 Mar 2002, Yuri Peter Kazakov wrote:
Hello,
how can I use JS functions in EL, for example:
c:if test=${ a.indexOf( b ) 0 }
doesn't work.
Any ideas?
Regards,
Yuri.
You can't. The JSTL expression language is really just for simple
references to request parameters, attributes, and other commonly accessed
data. For more complex operations -- e.g., on Strings and Collections --
I suggest using custom tag libraries. Having said that, the EL may grow
slightly to include some common functionality, either for JSTL 1.0 or JSP
1.3. These features are still being debated.
--
Shawn Bayern
Author, JSP Standard Tag Library http://www.jstlbook.com
(coming this summer from Manning Publications)
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: several messages
On Sat, 30 Mar 2002, Ming Fai wrote:
The default path of xmlUrl is not webapps/, but the bin/ directory of
Tomcat (I use tomcat 4.03). It is suggested in an old post (From:
Stefan Kost, Date: Mon, 22 Oct 2001 02:28:37) that user.dir can be
reset to webapps path. This method does work, but I think it is not
good enough, as one of the reasons for using taglib is to avoid
writing any Java code in the jsp pages. So, is there a better way to
pass webapps path to the xmlUrl? e.g. use a ${webapps} variable etc.
Hi there. This is an excellent question. It's been reported as a bug
(#7500) in the Bugzilla archive by [EMAIL PROTECTED], although it's
actually a spec matter. The expert group will need to figure out exactly
what the semantics of relative URLs in the XML tags will be, whether
documents should be validated by x:transform and x:parse, and whether
such considerations affect reasonably implementability. These issues will
probably be addressed before our Public Final Draft (and next RI beta).
Thanks again for raising the issue.
--
Shawn Bayern
Author, JSP Standard Tag Library http://www.jstlbook.com
(coming this summer from Manning Publications)
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: problems with sql and fmt using JSTL beta 1 version
Helen,
1. SQL result display problem.
I successfully retrieve the resultset using
c:forEach var=column items=${row}
tdc:out value=${column}//td
/c:forEach
However, the following code retrieves blank values. I can see multiple empty
lines, which means the query is successful, but all the values are blank.
c:forEach var=row items=${project.rows}
tr
td c:out value=${row.proj_name}/ /td
td c:out value=${row.task_name}/ /td
td c:out value=${row.task_status}/ /td
td c:out value=${row.act_name}/ /td
td c:out value=${row.activity_status}/ /td
/tr
/c:forEach
If I had to guess, I'd say that there's a mismatch between the column
capitalization that your database is returning and the ones that you're
using in your expressions (e.g., proj_name versus PROJ_NAME). JSTL is
currently case-sensitive in this regard, although we're actively
considering whether (and how) to make it case insensitive.
One easy way to tell for sure if column-name mismatches are at the root of
your problem is to use 'result.rowsByIndex' instead of 'result.rows' and
then to access column numbers instead of names.
2. fmt:message cannot properly display text
I am only using fmt:message tag, all the messages are displayed as
???. If I type in a non-exist value as either key or message tag's
body content, it at least displays the original value. For example
fmt:message key=engineering_name / (engineering_name doesn't exist in
resource bundle)
displays:
???engineering_name???
This seems to me indicate that fmt tag is able to locate the bundle
and key, but is not able to display it.
Similar to what Jan said, this sounds just like the tag isn't finding your
bundle. (As Jan said, the name for the parameter/attribute changed.)
--
Shawn Bayern
Author, JSP Standard Tag Library http://www.jstlbook.com
(coming this summer from Manning Publications)
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: standard tag library XML example failures
On Wed, 27 Mar 2002, Steve Spradlin wrote: The product I work with currently uses the xsl taglib available through Jakarta. We are very interested in converting to the new standard tag library. I downloaded the beta 1 standard tag library in order to review its capabilities. It looks to me like we could really use it for style sheets and other things. However, the XML examples are not working for me in the standard-examples. I tried getting the latest jaxp and then xalan hoping my problem would be solved with no luck. I have attached the exception below. Has anyone experienced this? Ha - I have. :-) I dealt with lots of different configurations of JARs in trying to determine the most timely, compatible, and convenient set of libraries to use for the out of the box standard-examples.war. (It's been a moving target for a while, so I can empathize with it not being easy to track.) The short answer, since I'm at JavaOne now and don't have time to suggest specific URLs and versions, is to use the set of JARs distributed in standard-examples.war (under WEB-INF/lib). This is the prepackaged version of our JSTL example pages, and it's distributed with the RI from jakarta.apache.org/taglibs. Hope that helps for the short term. If you remind me when I have more time, I can describe the histories and principles associated with the distributions of the various XML parsing and transformation libraries. But it's probably just as well that I don't (since it's not particularly interesting). :-) -- Shawn Bayern Author, JSP Standard Tag Library http://www.jstlbook.com (coming this summer from Manning Publications) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Standard taglib - sql problem
Thanks for the report.
This is actually a minor bug in the return value of the RI's sql:query
(and sql:update) tag. I've notated the problem in our bug-tracking
system; it'll get fixed soon after JavaOne (or possibly before, if other
RI team members have a more fluid environment than do I, currently writing
from a JavaOne kiosk). :-)
Thanks again,
--
Shawn Bayern
Author, JSP Standard Tag Library http://www.jstlbook.com
(coming this summer from Manning Publications)
On Thu, 28 Mar 2002, Andrea Grittini wrote:
I have the same problem using the sql jstl.
When I connect to a DB I got an exception in the DoEndTag method.
I just used this tag:
sql:driver var=myDataSource
driver=sun.jdbc.odbc.JdbcOdbcDriver
url=jdbc:odbc:guestbook
/
sql:query var=pro dataSource=${myDataSource} sql=select * from GuestBook /
There is a workaround to get the recordset using this taglib??
This is quite urgent.
Thank you
This is the server output:
A program exception has occurred:
javax.servlet.jsp.JspException: Illegal action
returned from doEndTag() method.
at
JspPage_QueryIterate_jsp_Impl._jspService(JspPage_QueryIterate_jsp_Impl.java:201)
at
com.hp.mwlabs.j2ee.containers.servlet.jsp.AbstractJspPage.service(AbstractJspPage.java:551)
at
com.hp.mwlabs.j2ee.containers.servlet.jsp.JspServlet._service(JspServlet.java:766)
at
com.hp.mwlabs.j2ee.containers.servlet.jsp.JspServlet.service(JspServlet.java:424)
at
com.hp.mwlabs.j2ee.containers.servlet.WebApplicationBean$ServicePrivilegedAction.run(WebApplicationBean.java:4493)
at
java.security.AccessController.doPrivileged(Native Method)
at
javax.security.auth.Subject.doAsPrivileged(Subject.java:558)
at
com.hp.mwlabs.j2ee.containers.servlet.WebApplicationBean.service(WebApplicationBean.java:1977)
at
com.hp.mwlabs.j2ee.containers.servlet.RequestDispatcherImpl.forwardOrInclude(RequestDispatcherImpl.java:405)
at
com.hp.mwlabs.j2ee.containers.servlet.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:134)
at
com.hp.mwlabs.j2ee.containers.servlet.ServletContainerBean.processRequest(ServletContainerBean.java:772)
at
com.hp.mwlabs.as.services.servlet.ServletContainerService.processRequest(ServletContainerService.java:542)
at java.lang.reflect.Method.invoke(Native Method)
at
com.hp.mw.common.util.PolymorphicInvocationHandler.invoke(PolymorphicInvocationHandler.java:223)
at
com.hp.mwlabs.csf.ServiceInvocationHandler.invoke(ServiceInvocationHandler.java:184)
at $Proxy87.processRequest(Unknown Source)
at
com.hp.mwlabs.as.services.listeners.http.HttpRequestHandler.executeImpl(HttpRequestHandler.java:229)
at
com.hp.mw.as.services.listeners.BaseRequestHandler.execute(BaseRequestHandler.java:124)
at
com.hp.mwlabs.common.util.ExecutorPool$Entry.execute(ExecutorPool.java:400)
at
com.hp.mwlabs.common.util.PeriodicExecutor.run(PeriodicExecutor.java:630)
at java.lang.Thread.run(Thread.java:484)
Andrea Grittini ( mailto:[EMAIL PROTECTED])
Tel: +39-2-97482.1- Fax: +39-2-97482?
Computer Design S.r.l., Via Piave 46 - 20010 S.Stefano Ticino - ITALY
http://www.cdesign.it/
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: regression in the standard-beta1 ?
As David mentioned, the new Public Draft available at jcp.org explains the
new behaviors. Just to explain where they come from (so they don't seem
arbitrary):
On Wed, 27 Mar 2002, Jean-Paul Le Fevre wrote:
- I've a class which is extended from an AbtractList. I added some
methods which are needed by my application (A couple of getSomething())
but in my JS page, using c:out value=${my_instance.something},
an exception is raised complaining that a conversion to integer (?)
is not possible for a List. It seems that the server does not
understand that my_instance is not a pure List but something
inheriting from a List.
To clarify, this was intentional. The spec reasons that if you provide a
an object that implements List, you're supplying a list of items -- and
that you don't intend for the object to supply arbitrary JavaBean
properties.
- In a class I've a method preparing the list of options available
for some choice : getOptionList(). It returns a string which is
a concatenation of optionchoice A/option ...
But in the JSP c:out value = ${sample.optionList} / is not displayed
if it is nested in a select/select where it should be.
To find out what was wrong I moved the c:out outside the select
block and my string was displayed.
By default, c:out escapes characters that have special meaning to XML.
It's far more common to use c:out to display a simple (non-HTML) string,
where escaping is appropriate. To shut off this escaping, set the
'escapeXml' attribute to 'false'.
Hope that helps,
--
Shawn Bayern
Author, JSP Standard Tag Library http://www.jstlbook.com
(coming this summer from Manning Publications)
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: How to get request parameter using c taglib ?
On Mon, 25 Mar 2002, RAYMOND Romain wrote:
Specs indicate c:out value=${request:myparameter}/ to do an
equivalent to request.getParameter(myparameter) but it is not good
...
Have you the right syntax ?
The current specs don't say that. Are you reading documentation that's
out of date? (If not, let me know what gives that incorrect syntax.)
You can access a request parameter named 'myParameter' as:
${param.myParameter}
Shawn
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: failure of c:import
On Mon, 25 Mar 2002, Biske, Todd wrote: Is there a way using c:catch or some other mechanism to trap exceptional HTTP response codes, e.g. 4xx and 50x codes and perform action on them? When using this tag for include portlets from other contexts, it would seem that this type of functionality is critical. Todd -- great question. This is currently in flux; we're discussing how best to handle error conditions in c:import. It'll most likely be decided before JSTL's public final draft (PFD). -- Shawn Bayern Author, JSP Standard Tag Library http://www.jstlbook.com (coming this summer from Manning Publications) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Can you test for a cookie's value using c:if tag?
On Sat, 23 Mar 2002, Matt Raible wrote: Is there anyway to test if cookieValue *contains* a String, rather than just == 'String'? No. For that, you'll need a custom taglib (or, of course, the dreaded scriptlet). :) Ultimately, I'd personally like to see some string support in JSTL (like Bay's string taglib); hopefully, that'll come up in JSTL 1.1. -- Shawn Bayern Author, JSP Standard Tag Library http://www.jstlbook.com (coming this summer from Manning Publications) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: JSTL EL parser pool?
On Fri, 22 Mar 2002, peter lin wrote: I've been doing benchmarks with JSTL on some dynamic pages and noticed under medium heavy load 4-64 concurrent connections, the performance degrades rapidly. I looked at ExpressionEvaluatorManager and it looks like it doesn't create a pool of parsers. I posted some benchmarks on tomcat user mailing list http://www.mail-archive.com/tomcat-user@jakarta.apache.org/msg48946.html It might be beneficial to recyle the parsers. this way it would reduce memory usage and gc. The reason I say is because I am witnessing heavy disk caching with 4+ concurrent connections. These problems might be solved by adding 1gig of memory, but that would only be a temporary fix, especially for systems that can only support 2gigs of ram. Interesting thought, Peter. Given that instantiating an Evaluator object involves no specific logic on construction, the only cost of not having a pool is that of object creation itself, which should be exceptionally well optimized under any JIT. As a general rule, I strongly hesitate to pool objects unless there's a demonstrated reason it'll help. (Most products pool objects WAY too much, which leads to unnecessary complexity and -- indeed -- potential performance problems.) The performance you're experiencing doesn't sound too good, but do you have any reason to think that the logic within ExpressionEvaluatorManager (in particular) is to blame? The evaluator keeps a static cache of values, so literally the only benefit of pooling our interpreter instances would be to save the instantiation itself, which should take about ten low-level instructions on a modern JIT. (That is, the evaluator has an empty constructor, and all its work is done on the stack -- with the aid of a few static caches.) Thanks very much for the suggestion, though; I'd be curious if you have any data that does implicate one part of the JSTL RI over another. -- Shawn Bayern Author, JSP Standard Tag Library http://www.jstlbook.com (coming this summer from Manning Publications) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: JSTL EL parser pool?
On Fri, 22 Mar 2002, Shawn Bayern wrote: The evaluator keeps a static cache of values, so literally the only benefit of pooling our interpreter instances would be to save the instantiation itself, which should take about ten low-level instructions on a modern JIT. (That is, the evaluator has an empty constructor, and all its work is done on the stack -- with the aid of a few static caches.) By the way, this implies that a SINGLE instance, instead of a pool, would work just as well too. (The existing EEM code is from a time when this wasn't the case.) Once we're sure of the final EL interface, I'll plan on using just one instance. But again, the actual performance difference on an effective JIT should be negligible. -- Shawn Bayern Author, JSP Standard Tag Library http://www.jstlbook.com (coming this summer from Manning Publications) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Grouped Output
On Thu, 21 Mar 2002, Zvolensky, Thomas J {PDBI~Nutley} wrote:
Is it possible to generate a grouped report using taglibs without
resorting to using scriptlet logic to determine when the column Name
has changed in the record set?
Why not do it in the SQL itself using a group by clause? I used to
resist database logic too and attempted to do everything in my own
programs, but it's often easier to get the database to manage your data
for you.
--
Shawn Bayern
Author, JSP Standard Tag Library http://www.jstlbook.com
(coming this summer from Manning Publications)
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: JSTL tag prefix naming conventions?
So, sorry I didn't respond earlier; for some reason, the mailing list didn't send me these messages until hours later. Thanks for all your comments; I can't speak authoritatively for the entire expert group, but here are my own personal opinions. On Thu, 21 Mar 2002, Steve Bang wrote: While Java also supports meaningful naming, in this case the goal is to create tag libraries for non-programmers. So, names like x and fmt are not terribly clear. The HTML tags are not cryptic, and whenever possible, neither should JSP tags. Overall, I'd certainly never argue for tags that are cryptic, but HTML tags certainly use abbreviations, just for the sake of brevity. There's an a tag instead of anchor; p instead of paragraph; and img instead of image. In fact, nearly all HTML tags are cryptic if you don't like abbreviations. :-) Concerning analogies with Java, I'm not sure I agree. The J2SE libraries certainly use reasonably long names for classes, but namespace prefixes are more like packages, and the standard libraries all use abbreviations: java.io, java.util, java.lang. Like the J2SE libraries, we don't abbreviate the tag (class) names: forEach, forTokens (instead of 'f' or 'ft'). At any rate, it looks (to me) like we're in good company. I undestand that the HTML tags don't need a prefix, but we should keep in mind the intended audience and minimize confusion. If the standard JSP tags were j:useBean, j:setProperty, etc., it would be confusing -- would the j represent Java or JSP? And, if HTML tags had to have a prefix, would you find h a good prefix? I doubt it -- I'd much prefer html as a prefix. To avoid collisions and other confusion, I'm leaning toward having jstl at the beginning of the prefixes. Shawn, hasn't this issue been discussed among the expert group? Or, was this something no one ever thought about discussing? This definitely came up; it was debated at length in the context of whether to provide a single JSTL tag library or multiple tag libraries. The rationale for the perceived inconsistency in the naming is what Henri said: simplicity to type. After all, 'core' or 'jstlcore' are just as opaque as 'c' without ANY context; given that JSTL is the standard and is expected to be used widely, we figured that c:forEach would be much easier to read and identify than jstlcore:forEach FMT could be called 'f', but it does take a slight back-seat to the core library in this regard. I'd expect many pages just to use 'c'. The XML tag library might have ideally been prefixed 'xml', but the XML standard itself rules that out :-), and we figured we'd promote the library by giving it its own, one-letter abbreviation. Whatever we choose would be somewhat arbitrary, so we ultimately opted to ease the page author's burden of typing! -- Shawn Bayern Author, JSP Standard Tag Library http://www.jstlbook.com (coming this summer from Manning Publications) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: JSTL tag prefix naming conventions?
On Thu, 21 Mar 2002, Steve Bang wrote: OK, I guess I slipped on the intuitiveness of HTML tags -- I don't know where my mind was at that moment. Regardless, I prefer consistency and clarity whenever possible. I know you do too. Your clarified the issues and I am somewhat comfortable with the outcome. And, now I understand why sql was used, but not xml. Another advantage of the parallel between 'c' and 'x' is that it highlights the analogy between the two tag libraries. That is, you use 'c:out' to print data using the master expression language, and 'x:out' to print XML data using XPath. The same goes for 'if', 'set', 'when', and even 'forEach'. The parallelism might not be as clear if we called the tags 'xpath:out'. There's also an advantage in giving prominence to your XML support, these days. :-) I still think that it would be nice if all of the libraries started with jstl so that they appeared related. Oh, well. It's funny; I agreed with this in spirit as well for a long time. I initially had advocated using a 'j' prefix to distinguish JSTL tags, so that we'd end up with 'jc', 'jx', 'jf', and 'js' (so far). But this was (rightfully, I think) seen as MORE cryptic than the current system. Ultimately, I think that users will know they're looking at JSTL tags by virtue of general familiarity. But I agree -- any solution is somewhat arbitrary and imperfect. -- Shawn Bayern Author, JSP Standard Tag Library http://www.jstlbook.com (coming this summer from Manning Publications) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Can you test for a cookie's value using c:if tag?
On Thu, 21 Mar 2002, Matt Raible wrote:
Is it possible to do the following with JSTL?
c:if test=${cookie.username == 'learner'}
learner
/c:if
Ah, I was hoping someone would ask. The answer is no, not exactly like
that, but you can still use JSTL to access cookies.
While web developers often have the urge to access a cookie by name, it's
an urge that's best to resist; cookies aren't identified by name alone,
but by name, domain, path, and security status. Thus, the best way to
access a cookie is to loop over the list of available cookies, matching
the one that you're interested in.
Now, if you're just interested in name, that's fine; but JSTL doesn't go
out of its way to support that special case. Instead, you can just write
c:forEach items=${pageContext.request.cookies} var=cookie
c:if test=${cookie.name == 'learner'}
c:set var=cookieValue value=${cookie.value} /
/c:if
/c:forEach
I explain this in more detail in my book; interestingly enough, I just
wrote the section describing techniques like this.
--
Shawn Bayern
Author, JSP Standard Tag Library http://www.jstlbook.com
(coming this summer from Manning Publications)
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: JSTL EL support for header?
On Wed, 20 Mar 2002, peter lin wrote: I read through the JSTL spec and grepped org.apachelang.jstl to see if it has any calls to request.getHeader(string) and noticed JSTL EL does not support request header. It'll be added. In general, things like headers might ideally be retrieved as JavaBean-like properties of the PageContext. But headers aren't available this way, so they're going to be added as new top-level implicit objects. -- Shawn Bayern Author, JSP Standard Tag Library http://www.jstlbook.com (coming this summer from Manning Publications) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: xml taglib and standard-examples.war generating error
This actually doesn't look like a TransformerConfigurationException, but (because of the slashes) a ClassNotFoundError pointing to TransformerConfigurationException. You may need to update your container's XML-support libraries. -- Shawn Bayern Author, JSP Standard Tag Library http://www.jstlbook.com (coming this summer from Manning Publications) On Wed, 20 Mar 2002, RAYMOND Romain wrote: exact error is InsertTag:doEndTag caught: javax.servlet.ServletException: javax/xml/transform/TransformerConfigurationException hello, I am trying to use JSTL xml taglib to apply xsl to xml and i get an exception. So I have tried to look at standard-examples.war but all the xml examples (and a lot of the others) throws an exception too ? I use TC 4.0.3 (on Windows2000) and I have no problem using c.tld in my webapp, is there a configuration step I have missed, or any ideas ? thanks. -- 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: Argh :)
In JSP 1.2, you can't automatically use the JSTL expression language in
your own tags. You'll need to add support for that yourself by calling
the JSTL expression evaluator. As has come up on this list before, we
don't currently provide instructions for doing this because the final
interface is in flux. But it'll settle down before JSTL 1.0 is released.
--
Shawn Bayern
Author, JSP Standard Tag Library http://www.jstlbook.com
(coming this summer from Manning Publications)
On Wed, 20 Mar 2002, John Baker wrote:
Argh, this is driving me nuts.
Consider this:
c:forEach var=item items=${request.allItems}
c:if test=${session.selection != item}
(team:itemPath item=${item} factory=%= factory % /)
/div
/c:if
/c:forEach
Now you see the team: tag? Well I get this useful error:
Unable to convert string '${item}' to class
com.teamenergy.libraries.blend.domain.Item for attribute item:
java.lang.IllegalArgumentException: Property Editor not registered with the
PropertyEditorManager
My tld looks like:
attribute
nameitem/name
requiredtrue/required
rtexprvaluetrue/rtexprvalue
/attribute
So I'm assuming rtexprvalue == true means I can do this, but it keeps
interpreting ${items} as a String, which is highly unuseful. :(
Any ideas?
John
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: ${x}
On Wed, 20 Mar 2002, John Baker wrote:
When ${x} is passed to a tag, does the tag figure out what it means or
does the variable get decoded and passed to the tag?
In JSP 1.2, the tag handler interprets it itself. The expectation is that
under JSP 1.3, the container will do so.
If so, I'm sadly beginning to conclude that there seems no easy method
of mixing JSTL and your own tags (that provide links into a 200,000
line application 'under the hood'). It's very frustrating ;-)
You can just ensure your tags accept scoped variables, or call the JSTL
expression language manually from your tags.
--
Shawn Bayern
Author, JSP Standard Tag Library http://www.jstlbook.com
(coming this summer from Manning Publications)
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: ${x}
On Wed, 20 Mar 2002, Suryanarayana Murthy wrote: Could any one please tell me how can I use JSTL in my projects. I read that JSTL is still in development phase. If I would like to use JSTL for production development, can I do that? and also how to test JSTL tag libraries? Plesae tell me the procedure. Do I need to download any jar files from any site ? or are there any tutorials how to use JSTL? The JSTL specification is currently in Public Review under the Java Community Process. You can read the public draft at http://jcp.org/aboutJava/communityprocess/review/jsr052 Jakarta Taglibs hosts the reference implementation (RI) for JSTL, called the Standard Taglib. It's currently in Beta 1, which matches the spec draft closely. The expectation is that final versions of both the specification and the RI will be released in about two months. In the meantime, if you want to experiment with JSTL, you can download the beta Standard Taglib at http://jakarta.apache.org/builds/jakarta-taglibs/releases/standard This includes some WARs of JSTL examples, individual JARs you can use in your own applications, and documentation. The draft spec, however, provides full information on the way JSTL is supposed to work. There's also a tutorial at Sun's site: http://java.sun.com/webservices/docs/ea1/tutorial/doc/JSTL.html I'm also writing a book on JSTL. It should hit stores this summer. -- Shawn Bayern JSTL reference-implementation lead Author, JSP Standard Tag Library http://www.jstlbook.com (coming this summer from Manning Publications) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: My last annoying question of the day, promise.:-)
On Mon, 18 Mar 2002, John Baker wrote: That's a real minus point for JSTL. In defense of the way JSTL currently works, this isn't really its job. The design standard for components is JavaBeans, which outlines what's a property and what's not. -- Shawn Bayern Author, JSP Standard Tag Library http://www.jstlbook.com (coming this summer from Manning Publications) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: c:set value=${Integer.class}
On Tue, 19 Mar 2002, John Baker wrote:
Following on from my posts earlier (sorry it ended up going twice or
whatever, sendmail was lieing to me), I'm wondering if I can do:
c:set var=searchType value=${Integer.class scope=session/
c:if test=${session.searchType == Integer.class
/c:if
but I'm rather thinking I can't. Can anyone confirm this, and suggest
another way?
I'm not sure what you're asking, exactly. ${Integer.class} is a perfectly
valid expression, but it means the 'class' property of the scoped
variable named 'Integer'. It doesn't mean the result of the getClass()
method for the class Integer, if that's what you're asking.
If you had an individual Integer I, then ${I.class} would correspond to
the Class object for Integer.
--
Shawn Bayern
Author, JSP Standard Tag Library http://www.jstlbook.com
(coming this summer from Manning Publications)
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: My last annoying question of the day, promise.:-)
On Tue, 19 Mar 2002, John Baker wrote: When I was reading the spec, I got the impression this was possible: (section 6.1.5) c-rt:out value=%= SomeClass.COST %/ So I'm assuming that the c-rt tld will evaluate SomeClass.COST as the variable COST in the class SomeClass. But that doesn't seem to work either :-) %= SomeClass.COST % is an rtexprvalue; it means the same thing it means in Java: the public static variable COST in SomeClass. But this isn't an JSTL expression or even something that JSTL knows how to evaluate; this is just a traditional rtexprvalue. The two aren't intended to work the same. If they were, we wouldn't have needed an expression language! :-) -- Shawn Bayern Author, JSP Standard Tag Library http://www.jstlbook.com (coming this summer from Manning Publications) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: My last annoying question of the day, promise.:-)
On Tue, 19 Mar 2002, John Baker wrote:
Ok, one more before I shut up.
I'm trying to write this in JSTL:
if (request.getParameter(moo).equals(cows))
and so far I've got:
c:if test=${request.parameter.moo == 'cows'}
but it doesn't work ;-)
Yes, because request.parameter means the request-scoped variable named
'parameter'. To retrieve a parameter, use 'param.moo'.
Again, there isn't a one-to-one isomorphism between JSTL expressions and
rtexprvalues.
--
Shawn Bayern
Author, JSP Standard Tag Library http://www.jstlbook.com
(coming this summer from Manning Publications)
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: My last annoying question of the day, promise.:-)
On Tue, 19 Mar 2002, John Baker wrote:
Bah. So how can this be done in JSTL? It's a real shame because that
would be very nice. I'm trying to avoid writing Java ;-) Does this
mean I have to use the -rt stuff and do:
c-rt:if test=${ $=request.getParameter(moo).equals(cows) % }
No. Like I said, you can use an expression starting with 'param':
${param.moo == 'cows'}
I don't mind answering all your questions, but you might want to take an
hour and read through the entire JSTL draft spec! I think it'll answer a
lot of your questions. :-)
--
Shawn Bayern
Author, JSP Standard Tag Library http://www.jstlbook.com
(coming this summer from Manning Publications)
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: xml bug?
Peter,
Thanks for the bug report. There's actually no problem with the plumbing
of the XPathUtil class itself. It's correctly establishing the context
and passes it to our XPath engine. The problem was just that this XPath
engine wasn't resolving namespaces correctly.
I've fixed the problem by adjusting the matching logic to work against
prefixes, not namespaces. I've also made error checking more aggressive;
a variable that doesn't match with a value now fails immediately during
resolution.
I've checked in changes to the CVS archive that should fix your problem.
Best,
--
Shawn Bayern
Author, JSP Standard Tag Library http://www.jstlbook.com
(coming this summer from Manning Publications)
On Tue, 19 Mar 2002, peter lin wrote:
reading over my last paragraph, it's not clear what I meant, so here's a
second attempt. The current 3-19 nightly of XPathUtil.valueOf is below:
public String valueOf(Node n, String xpath) throws SAXPathException
{
staticInit();
XPath xp = new XPath(xpath);
return xp.valueOf(getLocalContext(n));
}
when it calls return, it the result of getLocalContext(node) to
XPath.valueOf(). when I output that result, I get zero length string.
the source for getLocalContext(node) is below.
private Context getLocalContext(Node n) {
// set up instance-specific contexts
VariableContext vc = new JstlVariableContext();
ContextSupport cs = new ContextSupport(nc, fc, vc, dn);
Context c = new Context(cs);
List l = new ArrayList(1);
l.add(n);
c.setNodeSet(l);
return c;
}
an instance of JstlVariableContext is passed to the constructor of
ContextSupport, but I don't see where
JstlVariableContext.getVariableValue() is called. Within
getLocalContext, should it check to make sure context was created
correctly when it does Context c = new Context(cs)?
when I output the result of the hsr.getHeader(localName), it never
reaches that chunk of code in getVariableValue().
else if (namespace.equals(HEADER_NS_URL)) {
HttpServletRequest hsr =
(HttpServletRequest) pageContext.getRequest();
return hsr.getHeader(localName);
thanks.
peter lin
peter lin
Should valueOf(node,string) check the result of
xp.valueOf(getLocalContext(n)) and call getLocalContext? I'm don't
completely understand XPathUtil. Any tips are greatly appreciated.
peter lin
--
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: My last annoying question of the day, promise.:-)
On Tue, 19 Mar 2002, John Baker wrote: What the spec fails to tell me is where customers came from. Is it a request attribute? A session attribute? Does it mean I can do this: Your questions all seem to concern the expression language. You should read Appendix A for information on how it works. -- Shawn Bayern Author, JSP Standard Tag Library http://www.jstlbook.com (coming this summer from Manning Publications) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: what can I do
On Tue, 19 Mar 2002, Jens Gersonde wrote: /ShowSource.jsp(10): Could not parse deployment descriptor: org.xml.sax.SAXParseException: Could not parse taglib, starting at line 3 probably occurred due to an error in /ShowSource.jsp line 10: %@ taglib prefix=c uri=http://java.sun.com/jstl/ea/core; % We'll need more information to help. It depends on the container you're using and how it's configured. Are you using standard-examples.war, a complete web-application archive for the JSTL examples? -- Shawn Bayern Author, JSP Standard Tag Library http://www.jstlbook.com (coming this summer from Manning Publications) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Standard taglib - sql problem
Interesting. The AbstractMethodError is apparently coming from a call to
the ResultSetMetaData object associated with your JDBC driver. The
underlying issue may result from either a bug or a version incompatibility
in the driver. But this issue raises a question of how JSTL should handle
errors like this. (I'll raise a related issue to the spec lead.)
Shawn
On Mon, 18 Mar 2002, Brett Morgan wrote:
I'm trying to get the following code to work, but I keep getting a
java.lang.AbstractMethodError exception. I've tested the connection in the scriptlet
and it works. As soon as I add the sql tag the Exception is thrown. I've also
included the stack trace.
%@ page import=javax.naming.*,javax.sql.* %
%@ taglib prefix=sql uri=http://java.sun.com/jstl/sql; %
%
Context initCtx = new InitialContext();
Context envCtx = (Context) initCtx.lookup(java:comp/env);
DataSource ds = (DataSource)envCtx.lookup(jdbc/Intranet);
pageContext.setAttribute(db,ds);
%
sql:query var=project dataSource=${db}
SELECT *
FROM user_task_project
/sql:query
type Exception
reportmessage Internal Server Error
description The server encountered an internal error (Internal Server Error) that
prevented it from fulfilling this request.
exception
javax.servlet.ServletException
at
org.apache.jasper.runtime.PageContextImpl.handlePageException(PageContextImpl.java:457)
at
org.apache.jsp.timesheet_0005fsummary$jsp._jspService(timesheet_0005fsummary$jsp.java:120)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:107)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServlet.java:202)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:382)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:474)
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:243)
at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:201)
at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2344)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:164)
at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
at
org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:170)
at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:170)
at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:163)
at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at org.apache.catalina.connector.http.HttpProcessor.process(HttpProcessor.java:1011)
at org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java:1106)
at java.lang.Thread.run(Thread.java:484)
root cause
java.lang.AbstractMethodError
at
javax.servlet.jsp.jstl.sql.ResultImpl$ResultMetaDataUtil.getMetaDataCache(ResultImpl.java:382)
at javax.servlet.jsp.jstl.sql.ResultImpl$ResultMetaDataUtil.(ResultImpl.java:209)
at javax.servlet.jsp.jstl.sql.ResultImpl.(ResultImpl.java:92)
at
org.apache.taglibs.standard.tag.common.sql.QueryTagSupport.doEndTag(QueryTagSupport.java:234)
at
org.apache.jsp.timesheet_0005fsummary$jsp._jspService(timesheet_0005fsummary$jsp.java:103)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:107)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServlet.java:202)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:382)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:474)
at
Re: More on c:if
On Mon, 18 Mar 2002, John Baker wrote:
I have a lot of this going on in my jsps:
if (something) {
// Some error message
return;
}
Is there a way of supporting this without using embedded tags, ie:
c:if test=!something
c:if test=!somethingElse
then do something
Cheers!
I'm not sure I understand exactly what you're asking. You can currently
write
c:if test=${not something and not somethingElse}
...
/c:if
and familiar boolean operatings (e.g., for and, || for or) will
likely be added to the EL before it's done.
If you're asking whether or not JSTL has a tag that aborts the current
page, the answer is currently no.
--
Shawn Bayern
Author, JSP Standard Tag Library http://www.jstlbook.com
(coming this summer from Manning Publications)
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: My last annoying question of the day, promise.:-)
On Mon, 18 Mar 2002, John Baker wrote:
I'm busy digesting the jstl spec now (found an error in it, it says you can
do c:url= and it should be c:url value=... :-), however I'm wondering
if I can put an array of objects into a request and use c:if test= to test
one. Ie:
Blob[] blobs = new Blob[100];
// fill blobs
request.setAttribute(blobs, blobs);
now can I do:
c:if test=${request.blobs[2].whatever ?
Cheers!
Yes, this should work.
--
Shawn Bayern
Author, JSP Standard Tag Library http://www.jstlbook.com
(coming this summer from Manning Publications)
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Struts Vs Taglibs
On Mon, 18 Mar 2002, Chen, Gin wrote: Just a curiousity question. What is the advantages of using one over the other? For example, alot of the tags seem to be doing the same type of tasks. (ex. Foreach versus Iterate). Why would one pick one approach over another? -Tim My impression is that Struts will eventually accommodate the standard taglib (JSTL) and integrate well with it. The other taglibs in Jakarta Taglibs are essentially just separate offerings from Struts, attempting to address different needs (or similar needs from a different perspective). -- Shawn Bayern Author, JSP Standard Tag Library http://www.jstlbook.com (coming this summer from Manning Publications) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: How to pass parameters to method in c:if
On Mon, 18 Mar 2002, Trogrlic Zeljko wrote:
Hello,
I'm writing a presentation of the latest JSTL, but I have a problem
with one example.
In JSP, I need something like
c:if test=${securityBean.check(request, response) }
but it doesn't work. How can I pass parameters? All examples use only
simple getters. If someone knows the answer please reply ASAP because
I have a presentation in two days.
Thanks!
The JSTL expression language does not support method invocations on
objects. You'll currently need to use a custom tag library or scriptlet
code (with the former being recommended over the latter) if you want to
access arbitrary methods and pass arguments to them.
--
Shawn Bayern
Author, JSP Standard Tag Library http://www.jstlbook.com
(coming this summer from Manning Publications)
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: How to pass parameters to method in c:if
On Mon, 18 Mar 2002, Dave Newton wrote:
On Monday 18 March 2002 02:43 pm, you wrote:
c:if test=${securityBean.check(request, response) }
The JSTL expression language does not support method invocations on
objects. You'll currently need to use a custom tag library or scriptlet
code (with the former being recommended over the latter) if you want to
access arbitrary methods and pass arguments to them.
So, from a non-current tag/etc. user does this mean that I'd either
want a custom tag for All Things Like That (i.e., c:ifsecurecheck
...) or, perhaps more OOish, c:ifcheck param=MyBean and use
reflection to call a common method for everything I'd ever want to
.check?
Tags are a great mechanism for providing abstraction. If you want a
facility to call arbitrary methods from within a JSP page, Java scriptlets
(% %) provide this already. Scriplets' problems don't just stem from
their syntax; they tend to make pages harder to maintain because they
don't create any meaningful abstraction.
Tags do. When you design tags, I simply recommend you choose the most
convenient abstraction for your users.
There's a theory in linguistic pragmatics (for actual human languages, not
CS languages) that suggests language is a tradeoff between laziness and
effectiveness; as a speaker, you want to be lazy, but as a listener, you
want the speaker to provide as much information as is necessary. Since
everyone is both a speaker and a listener, languages end up being
balanced: not too verbose or too clipped, on average.
Anyway, page authors and tag-library developers are in a similar
relationship. For every environment, there's a particular level of
verbosity that's appropriate; one isn't necessarily better than others.
JSTL works well with either approach; it encourages good design when
unambiguous, but otherwise tries to avoid preaching about how you must
design your applications.
--
Shawn Bayern
Author, JSP Standard Tag Library http://www.jstlbook.com
(coming this summer from Manning Publications)
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Double EL indirection in STL?
On Sat, 16 Mar 2002, Lee Crawford wrote:
I'm trying to determine if there's a way to express the equivalent of:
${${x}}
in the STL EL. This yields an exception in the current beta release of the
STL.
Good question, Lee. The EL doesn't support this, primarily (in my
opinion) because we didn't think that nonprogramming page authors would
need a feature like this. Adding a feature to a language means that all
users -- not just the advanced ones -- will have to understand it to be
able to maintain pages written by other users.
Have you run into a practical situation where this kind of indirection is
absolutely necessary?
--
Shawn Bayern
Author, JSP Standard Tag Library http://www.jstlbook.com
(coming this summer from Manning Publications)
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: JSTL tag forEach context question
On Fri, 15 Mar 2002, John Baker wrote: Stupid question. What is the difference between c.tld and c-rt.tld ? Or in general, what does -rt dictate? The 'rt' versions of each tag library support rtexprvalues instead of the expression language. We included them primarily as a way of facilitating integration of JSTL into older applications and methodologies. The 'rt' versions won't be necessary once JSP itself supports the expression language. Section 1.3 of the JSTL Public Draft describes the situation more completely. -- Shawn Bayern Author, JSP Standard Tag Library http://www.jstlbook.com (coming this summer from Manning Publications) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: JSTL tag forEach context question
On Fri, 15 Mar 2002, John Baker wrote:
The 'rt' versions of each tag library support rtexprvalues instead of the
expression language. We included them primarily as a way of facilitating
integration of JSTL into older applications and methodologies. The 'rt'
versions won't be necessary once JSP itself supports the expression
language.
Section 1.3 of the JSTL Public Draft describes the situation more
completely.
I see. That does make a lot more sense. But I don't understand this:
The 'rt' versions won't be necessary once JSP itself supports the
expression language.
JSP 1.3 has plans to support an expression language through the entire JSP
page (not just for custom-tag attributes). Given this, there eventually
won't be a need for two different versions of each JSTL tag library. In
the future, one could write:
c:forEach items=${session.data}
and
c:forEach items='%= session.getAttribute(data) %'
against the same tag library (TLD and tag handlers).
Technically, this would be possible now; that is, the same tag handler
could support both. But since, under JSP 1.2, a tag handler can't figure
out whether it retrieved a String using an rtexprvalue or whether or not
that String was passed literally, we had to account for the situation
where an rtexprvalue would return something that looked like an
expression; this would cause an undesirable (and perhaps insecure) double
evaluation. For instance, something as simple as
You said your name was c:out value='%= request.getParameter(foo)'/
would not necessarily be secure. Why? Because getParameter(foo) is
under the user's control, meaning that it could be set to something like
${session.secureData}, at which point the tag would evaluate this result
as an expression, causing the tag to expose secure data unintentionally.
To address this, we first thought to use two different attributes for each
tag (e.g., items and items_), but this got to be cumbersome very
quickly, and the syntax was ugly. Other alternatives included an
attribute-based switch for each tag (e.g., expressions=true), but this
wasn't convenient and would need to operate on the level of each
individual attribute in order to be granular enough. Parent tags that
adjusted subtags' evaluative algorithm could have worked, but were
somewhat dangerous and difficult to explain. Thus, we opted for two
parallel tag libraries. It lets you make the decision once and then
forget about it again until you need to re-evaluate.
In JSP 1.3, the extra tag library can likely go away because evaluation of
rtexprvalues and 'elexprvalues' will occur at the same level of
abstraction; expression-language evaluation won't be subordinate to
rtexprvalue execution.
So, are you sorry you asked yet? :-)
--
Shawn Bayern
Author, JSP Standard Tag Library http://www.jstlbook.com
(coming this summer from Manning Publications)
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: JSTL tag forEach context question
On Fri, 15 Mar 2002, RAYMOND Romain wrote: and is there a solution without rt (which seems dedicated to hard programming ) about passing parameter within a foreach tag ? No. Calling methods directly is considered hard programming for now. The question is - should it be in the future? -- Shawn Bayern Author, JSP Standard Tag Library http://www.jstlbook.com (coming this summer from Manning Publications) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: c:if
On Fri, 15 Mar 2002, John Baker wrote: Does c:if support else? ie if (x) something(); else somethingElse(); or do I have to use c:choose? You need to use c:choose. This comes about for somewhat intricate technical reasons, and is never a unanimously popular choice, but it was considered to be both the safest and the most general. -- Shawn Bayern Author, JSP Standard Tag Library http://www.jstlbook.com (coming this summer from Manning Publications) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: c:if - testing for request parameter value
On Thu, 14 Mar 2002, Matt Raible wrote:
I'm trying to use JSTL do check for values of certain variables. For instance,
I want to find out if the action parameter (passed in via URL) is equal to
Edit. However, my code below is not working:
c:if test=${request:action == 'Edit'}
I detected you where trying to edit me
/c:if
I get an error stating that:
action is not defined.
Please send responses to [EMAIL PROTECTED] as I am not subscribed
to this list.
Matt,
The JSTL expression language has changed. You should now write
${param.action == 'Edit'}
Actually, 'request:action' would have never indicated a request
parameter; it would have indicated a request-scoped variable
(attribute). Now, you'd use ${request.action} to indicate the 'action'
variable in 'request' scope.
--
Shawn Bayern
Author, JSP Standard Tag Library http://www.jstlbook.com
(coming early this summer from Manning Publications)
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: JSTL tag forEach context question
On Thu, 14 Mar 2002, RAYMOND Romain wrote: I initilize my collections using beans : % Collection serialNos = datamodule.getAllApplicableSerialNos(HAP); % and I must use pageContext.getAttribute to get back iterators values : c:forEach var=serial items=%= serialNos % option%= pageContext.getAttribute(serial) %/option /c:forEach Is ot normal and is there a way to do it without accessing pageContext, using only current and normal runtime ? If you need to use the 'rtexprvalue' library and scripting variables, you can declare the scripting variables with a jsp:useBean tag: c:forEach var=serial ... jsp:useBean id=serial type=... / option%= serial %/option /c:forEach -- Shawn Bayern Author, JSP Standard Tag Library http://www.jstlbook.com (coming this summer from Manning Publications) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: JSTL: Nightly build crashes
On Thu, 14 Mar 2002 [EMAIL PROTECTED] wrote: - For I18N, the Parametric Replacement and Date example gives me javax.servlet.ServletException: Unparseable date: I'll let Jan answer this if he gets a chance, since he's more qualified to answer I18N-related questions than I am. - Also, for the Import, the Encode examples make no difference, I get ABC abc 123 123 JSTL is fun JSTL is fun Doesn't look really different IMHO I'm sorry if these are dummy questions :-) No, this is a great question. The answer is that on Tomcat, the c:url tag won't rewrite the URL (to add a session) unless it needs to. Needs to is defined through a number of criteria, but the notable one is that if your browser supports cookies, it won't do the rewriting. (It simply doesn't need to.) I've also seen reports that a recent version of Tomcat had some trouble with the HttpServletResponse.encodeURL() method, which would also cause problems for c:url. But I don't know offhand the version where it's problematic. -- Shawn Bayern Author, JSP Standard Tag Library http://www.jstlbook.com (coming this summer from Manning Publications) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: x:transform and nightly build
I think the problem is just that you need to specify ${xsl} instead of
$xsl as the attribute value for xsltText. The latter is now interpreted
as a string literal.
I've slowly been coming to the realization that allowing $foo as a string
literal leads to errors that are hard to track down; I'm just not sure
what to do about it.
--
Shawn Bayern
Author, JSP Standard Tag Library http://www.jstlbook.com
(coming this summer from Manning Publications)
On Thu, 14 Mar 2002, Matt Raible wrote:
The following code was working before I updated to last night's build:
c:import url=/styles/assets.xsl var=xsl/
x:transform xsltText=$xsl
asset
typeimage/pjpeg/type
pathfile://D:/Source/onpoint/prototype/media//path
file height=240 width=320
transmission_removal.jpg
/file
/asset
/x:transform
Now I get the following error:
[ServletException in:/pages/assetPreview.jsp]
javax.xml.transform.TransformerConfigurationException:
javax.xml.transform.TransformerConfigurationException:
javax.xml.transform.TransformerException: org.xml.sax.SAXException:
Content is not allowed in prolog.'
Any ideas?
Matt
My stylesheet - asset.xsl - is as follows:
?xml version=1.0 encoding=UTF-8?
!-- XSL Stylesheet for rendering assets within an HTML page --
xsl:stylesheet
version=1.0
xmlns:xsl=http://www.w3.org/1999/XSL/Transform;
!-- Output method --
xsl:output method=html indent=yes/
xsl:variable name=newline
xsl:text
/xsl:text
/xsl:variable
!-- Process assets into HTML tags to view them --
xsl:template match=asset
xsl:variable name=path select=path/
xsl:variable name=file select=normalize-space(file)/
xsl:variable name=type select=type/
xsl:variable name=height select=file/@height/
xsl:variable name=width select=file/@width/
xsl:variable name=src
xsl:value-of select=concat($path, $file)/
/xsl:variable
xsl:choose
!-- Render HTML for videos --
xsl:when test=$type='video/quicktime'
embed src={$src}
id=mediaFile name=mediaFile
height={$height} width={$width} autostart=true
pluginspage=http://quicktime.apple.com;
type={$type}/
/xsl:when
!-- Render HTML for audio --
xsl:when test=$type='audio/wav'
embed src={$src}
id=mediaFile name=mediaFile
height={$height} width={$width} autostart=true
pluginspage=http://quicktime.apple.com;
type={$type}/
/xsl:when
!-- Render HTML for HTML documents and text documents. --
xsl:when test=$type='text/html' or $type='text/plain'
iframe id=mediaFile name=mediaFile src={$src}
height={$height} width={$width}/iframe
/xsl:when
!-- Render HTML for images --
xsl:when test=$type='image/pjpeg' or $type='image/gif' or
$type='image/jpeg'
img id=mediaFile name=mediaFile src={$src}
height={$height} width={$width}/
/xsl:when
/xsl:choose
/xsl:template
/xsl:stylesheet
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Standard taglib problem
On Wed, 13 Mar 2002, John Baker wrote:
Can you be more specific to what I should be looking for? The file I'm
including has a load of other jsp imports, etc that do not cause it to
screw up. I'm quite happy to look for the problem, if I know what I'm
looking for ;-)
Thanks for that quick response!
Oh, sorry - I didn't realize you were speaking of an entire application.
If you could attempt to figure out which piece of the page causes the
error, that would be the best first step.
Typically, errors like the one you mentioned are caused by things like
forgetting to close a tag: e.g., c:out value=${foo}.
Shawn
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: ldap support
On Tue, 12 Mar 2002, Agrawal, Anuj (Anuj)** CTR ** wrote: Is any LDAP support planned for JSTL? I'd like to be able to query an LDAP server and use the forEach action to cycle over the results. JSTL 1.0 won't support JNDI (or thus LDAP). Speaking very speculatively, I believe the idea at one point was that J2EE technologies would be covered more thoroughly in JSTL 1.1, the (presumably) next version of JSTL. But again, that's just speculation. -- Shawn Bayern Author, JSP Standard Tag Library http://www.jstlbook.com (coming this spring from Manning Publications) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: ldap support
On Tue, 12 Mar 2002, Craig R. McClanahan wrote: Shawn, Would it be possible to include some docs (maybe with a sample Hello, World type tag) to illustrate how the expression language support can be used in non-JSTL tags? This would be tremendously useful to other tag authors who want to follow this suggestion (which I think is a good one). Sure. Once the interface has been finalized (there's still some debate in the 052 group about the best way to publicize this interface), I'll include an example in the JSTL RI. (The few advanced chapters at the end of my book also discuss stuff like this in some detail.) -- Shawn Bayern Author, JSP Standard Tag Library http://www.jstlbook.com (coming this spring from Manning Publications) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: JSP source
On Tue, 12 Mar 2002, Agrawal, Anuj (Anuj)** CTR ** wrote: Is there a way to display the source code for a particular JSP page? I'd like to have a link at the bottom of the page which will display the source (for the curious) when clicked on - very much like the way the SourceForge site has it setup. Take a look at the ShowSource.jsp file in the JSTL RI examples application (standard-examples); it might do exactly what you want. It uses the c:import tag. Shawn -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[JSTL] Announcing Public Review / RI Beta 1
Taglibs community, The JSP Standard Tag Library (JSTL) just entered its Public Review stage under the Java Community Process, and Beta 1 of the reference implementation (RI) is now available through Jakarta Taglibs. This new draft spec and RI milestone solidifies JSTL in a number of respects. After a lot of productive deliberation, the expert group determined the syntax for a single expression language; gone are the vaguely documented, pluggable languages. We've also introduced a few new minor tags and made many tags more flexible and robust. This release includes improved support for all of JSTL's features: support for iteration, conditional logic, URL management (including URL-based information retrieval), XML manipulation, database access, text formatting, and internationalization. The RI (Beta 1) is available at http://jakarta.apache.org/builds/jakarta-taglibs/releases/standard/ You can read the JSTL public draft at http://jcp.org/aboutJava/communityprocess/review/jsr052 Community feedback is still actively sought. You can mail comments to [EMAIL PROTECTED] Remember, the RI and spec are still subject to change, but we're getting closer and closer to final release. Enjoy! -- Shawn Bayern JSTL reference-implementation lead Author, JSP Standard Tag Library http://www.jstlbook.com (coming this spring from Manning Publications) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: c:set and scriptlets
On Mon, 11 Mar 2002, Agrawal, Anuj (Anuj)** CTR ** wrote: In my code i have c:set var=x value=4/ I'd like to be able to access the variable x from within a scriptlet, something like: % x = x++; % and vice versa. Is this even possible? I don't see anything in the docs that refer to such interchangeability. 8( JSTL doesn't particularly encourage this usage, but it's perfectly possible using older, scriptlet-oriented mechanisms like jsp:useBean. Just use a jsp:useBean tag after c:set to declare your scripting variable. -- Shawn Bayern Author, JSP Standard Tag Library http://www.jstlbook.com (coming this spring from Manning Publications) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: c:set and scriptlets
Anuj was writing about the JSTL tag c:set, though. JSTL de-emphasizes
scripting variables in favor of the expression language it introduces.
Scripting variables are a reasonable mechanism for some applications, but
they inherently depend on scriptlets, which means that they're useful only
if a page author knows something about Java. Scripting variables can also
be confusing many situations. For instance, consider the following code:
%-- Sets a scoped attribute four with the value of 4 --%
c:set var=four value=${2 + 2}/
%-- Declares a scripting variable four to match this scoped var --%
jsp:useBean id=four type=java.lang.Number/
%-- Replaces the scripting variablr four with the value 5 --%
% four = new Integer(5); %
%-- Prints out the value of the scoped variable four --%
c:out value=${four}/
What do you expect the final c:out tag to output? You might think 5
because you replaced the scripting variable 'four' with an Integer object
for the number 5. But the tag actually prints out 4, because changing a
scripting variable doesn't change the scoped variable that it was
originally tied to.
--
Shawn Bayern
Author, JSP Standard Tag Library http://www.jstlbook.com
(coming this spring from Manning Publications)
On Mon, 11 Mar 2002, Mark R. Diggory wrote:
See my last message about multipart stuff. You can capture this
functionality in TEI (TagExtraInfo) Support class to your tag. Then in
your tag you can set the value of the variable via a special method
which you have to define.
!-- Straight off the javadoc
public abstract class TagExtraInfo
extends java.lang.Object
Optional class provided by the tag library author to describe additional
translation-time information not described in the TLD. The TagExtraInfo
class is mentioned in the Tag Library Descriptor file (TLD).
This class can be used:
* to indicate that the tag defines scripting variables
* to perform translation-time validation of the tag attributes.
...
--
-Mark Diggory
Shawn Bayern wrote:
On Mon, 11 Mar 2002, Agrawal, Anuj (Anuj)** CTR ** wrote:
In my code i have c:set var=x value=4/
I'd like to be able to access the variable x from within a scriptlet,
something like:
%
x = x++;
%
and vice versa.
Is this even possible? I don't see anything in the docs that refer to
such interchangeability. 8(
JSTL doesn't particularly encourage this usage, but it's perfectly
possible using older, scriptlet-oriented mechanisms like jsp:useBean.
Just use a jsp:useBean tag after c:set to declare your scripting
variable.
--
Shawn Bayern
Author, JSP Standard Tag Library http://www.jstlbook.com
(coming this spring from Manning Publications)
--
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: 2nd try: Using set to change scope
Ah, I meant to try to answer this, but it slipped through...
I wasn't sure exactly what you meant by change the scope on one of the
attributes on our tags. You can use c:set to override an existing
attribute, and thus to change the scope of a scoped variable:
c:set var=foo scope=session value=${page.foo}/
but I'm not sure if that's what you mean.
You can't make the 'scope' attribute dynamic, which might be another thing
you mean. That is, you can't say scope=${myscope}. This restriction is
designed primarily to aid tool support and translation-time error
checking. If you need to decide on the fly what scope to use, you'll need
to use a c:if or c:choose block. We didn't consider this case very
common, so the somewhat circuitous solution didn't seem to be a major
issue. (Hmm, that's the first I've used the word circuitous to actually
refer to circuit-like logic. I wonder if that counts as a pun or not...)
--
Shawn Bayern
Author, JSP Standard Tag Library http://www.jstlbook.com
(coming this spring from Manning Publications)
On Mon, 11 Mar 2002, Steve Bang wrote:
Can anyone help me on this?
Thanks,
Steve
-Original Message-
From: Steve Bang [mailto:[EMAIL PROTECTED]]
Sent: Friday, March 08, 2002 11:03 AM
To: 'Tag Libraries Users List'
Subject: Using set to change scope
We have a custom tag library that treats all of our tags with
a session scope (by design). Is it possible to use JSTL's
c:set tag to change the scope on one of the attributes on
our tags? Users are requesting the ability to dynamically
change an attribute value on our tags when a page is refreshed,
but so far this is not possible within the tags themselves --
they are only interpreted the first time a page loads. If
so, do we have to modify our tag library to support this?
Steve
--
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: [standard] where did c:declare go?
On 8 Mar 2002, Glenn R. Kronschnabl wrote: From the nightlies standard taglib, it appears that c:declare is gone? It was removed from the c.tld and c-rt.tld but the source still appears. What's the replacement? Good question. There isn't one. We decided it was not in line with JSTL's approach, and also unnecessary. You can use jsp:useBean to declare a scripting variable, so we didn't need to provide support in JSTL -- especially given that JSTL is de-emphasizing them. Best, -- Shawn Bayern Author, JSP Standard Tag Library http://www.jstlbook.com (coming this spring from Manning Publications) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: recordcount?
On Sat, 2 Mar 2002, Agrawal, Anuj (Anuj)** CTR ** wrote: After using the JSTL sql:query var=myQuery action, is there an easy way to obtain myQuery.recordcount? Basically a count of the number of records returned by the query. Yes: myQuery.size. The 'Result' interface that sql:query exposes contains a getSize() method, which translates to a 'size' property. -- Shawn Bayern Author, JSP Standard Tag Library http://www.jstlbook.com (coming this spring from Manning Publications) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: attribute initialization
On Thu, 28 Feb 2002, Thomas Colin de Verdiere wrote: if we had : mytags:MyTag attr1=true/ //first mytags:MyTag/ // second instance then for the second instance attr1 is not false but true : as the container could use MyTag first instance from the first instanciation. This is a very good question to ask, but it's actually based on an incorrect assumption. The container cannot reuse the same MyTag instance from the first invocation to the second, precisely because its set of attributes is different. Section JSP10.1.1 in the JSP 1.2 spec says the following: tag handlers can only be reused within the same AttSet (set of attributes that have been set). If my memory is correct, the question you ask is exactly the reason that the spec lays out this requirement: if it didn't, you'd have no place to sensibly initialize default values for subsequent invocations that used fewer attributes than their predecessors. The practical answer is, thus, You don't need to worry about it. Initializing the instance variable as boolean attr1 = false; is fine. -- Shawn Bayern Author, JSP Standard Tag Library http://www.jstlbook.com (coming this spring from Manning Publications) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Will Using Tagged Libraries Affect Performance
On Wed, 27 Feb 2002, Burr Sutter wrote:
I think it could have a negative impact on performance. Why? Many
servlet containers will instantiate and then throw away the tag
handler class with each use on the page. So, if a tag handler requires
lots of setup (e.g. connect to a database, issue a query, check some
session or request attributes) then it could add significant time to
the loading of a page.
Right. Since instantiation itself is considerably cheaper than most
developers expect, though, a properly written tag handler can get around
these issues. For instance, connection pooling in general is recognized
as a useful methodology; a tag handler's constructor shouldn't ordinarily
need to open a database connection from scratch.
In general, tags (by themselves) shouldn't have a substantial effect on
performance. The only thing that a simple tag adds, in comparison to a
corresponding scriptlet, is a few function invocations; in a proper JIT,
these ought to be extremely cheap. (BodyTag implementations do require
the container to buffer body content, which can have a performance cost,
especially if the body content is extremely large.)
But assuming that the operations are like those you list (connect to a
database, issue a query, check some session or request attribute), the
difference between doing this in a scriplet and doing it in a tag should
be relatively minor. How minor? As a ballpark figure, using the
Benchmark Taglib on my Linux server at home, I don't notice any
significant difference between constructs like
benchmark:duration
% for (int i = 0; i 1; i++) { %
% if (Math.random() 0.5) { %foo% } %
% } %
/benchmark:duration
and
benchmark:duration
% for (int i = 0; i 1; i++) { %
c_rt:if test=%= Math.random() 0.5 %foo/c_rt:if
% } %
/benchmark:duration
Even the optimizations that some containers make, pooling tag handlers,
probably won't be particularly noticeable except in extremely tight loops
(like do this 1 times) when tag handlers are written properly.
--
Shawn Bayern
Author, JSP Standard Tag Library http://www.jstlbook.com
(coming this spring from Manning Publications)
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Suppress whitespace generation?
Hi Chris, The question is somewhat general. For instance, depending on your needs, you can write a tag that trims its BodyContent (using String.trim()) and simply contain other tags within it. So that: foo:trim foo /foo:trim would produce equivalent output to foo:trimfoo/foo:trim If you're suggesting, by contrast, that a particular taglib in Jakarta Taglibs produces unwanted whitespce, let us know, and the tag libraries could be patched to avoid this, or (as in the case of the Input taglib) to take a flag that switches behavior between pretty printing and avoidance of unnecessary whitespace. To help you further, I think we'd need more information about exactly what problem you're experiencing. -- Shawn Bayern Author, JSP Standard Tag Library http://www.jstlbook.com (coming this spring from Manning Publications) On Wed, 27 Feb 2002, Lomvardias, Christopher wrote: Haven't heard any responses to my earlier question below. Thought I'd poke the list again. Chris -Original Message- From: Lomvardias, Christopher [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 19, 2002 1:27 PM To: '[EMAIL PROTECTED]' Subject: Suppress whitespace generation? Hi, How does one suppress whitespace that is generated by a tag library? Thanks, Chris -- Chris Lomvardias [EMAIL PROTECTED] PublicBuy.Net 400 E. Pratt Street, Suite 300 Baltimore, MD 21202 (410)539-3737 x1722 voice (410)539-7302 fax [EMAIL PROTECTED] (pager via email) -- -- 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: jstl, request parameters
The final version of JSTL will most likely be substantially more lenient with respect to values that don't exist. Unfortunately, there's not much I can advise other than, Wait for the upcoming version! :-) (Such is the nature of early-access releases.) -- Shawn Bayern Author, JSP Standard Tag Library http://www.jstlbook.com (coming this spring from Manning Publications) On Wed, 20 Feb 2002, Steve Morrison wrote: I'm considering moving a large codebase of proprietary templates to jsp, and the jstl in particular. A problem I've had so far is with using SPEL and if tag. Such as: c:if test=$param:myParam == '1'do stuff/c:if and myParam does not exist in the url query string, an exception is thrown. We have many parameters that aren't required which initialize to default values, but we want an easy way to test against their existence in jsp. The request tag library has some nice ways of doing this, but I like the idea of using one set of tag libraries, not a mish-mash of many incompatible ones. I just don't think tags like this should throw exceptions on non-unrecoverable errors. Instead, it should just return an empty string (or some reasonable equivalent). a way around this would be to use Ecmascript to hold a reference to some object, which we use get/set methods on, for example: % request.setAttribute(req,request); % but we're having a hard time passing values to this object c:if test=$req.getParameterName(myParam).../c:if but the syntax doesn't seem to work - is there a way around this? -Steve -- 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: inner tag
On Fri, 15 Feb 2002, Ben Pezzei wrote: how is it possible to evaluate the inner tag lib? i read through the docs (eg EVAL_BODY_INCLUDE etc), but i think it's more difficult to accomplish this, than it looks like. As long as the body content for the outer tag (in the TLD) is JSP, the container will evaluate the inner tag (like any tag) when it comes to it. This evaluation occurs whether you return EVAL_BODY_INCLUDE or EVAL_BODY_BUFFERED from doStartTag() in the parent (outer) tag. The only difference between include and buffered is whether the output gets consumed by the outer tag or passed through it (either to another tag or, logically, to the page itself). For instance, suppose you have the text: foo:one one-foo:two /-three /foo:one If foo:two / prints the text two, then the body content of foo:one is equivalent to one-two-three. foo:one may buffer this content -- that is, receive it via a BodyContent object and interpret it (e.g., check it against some value, trim it, make it uppercase, or whatever else it wants to to) or it can simply pass it through. -- Shawn Bayern Author, JSP Standard Tag Library http://www.jstlbook.com (coming this spring from Manning Publications) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: inner tag
On Fri, 15 Feb 2002, Ben Pezzei wrote: somewhere in the String dbText could be another taglib eg bar:two/, completely independend from the outer tag foo:one/. and this inner tag wont be evaluated. i dont know, what i have to do with the out stream do reeavaluate it (eg check for a tag or something like this) There's nothing you can do, in this situation, to cause the container to evaluate foo:two/ as a JSP tag. You could always, of course, evaluate the string yourself and implement the tag protocol manually (e.g., call doStartTag(), check its return value, and so on). But the JSP container's job is (currently) to interpret the text that occurs in a JSP page, not to interpret JSP-like fragments that occur as data. (JSP 1.3 may have provisions to make something like this easier, but that's just a possibility.) -- Shawn Bayern Author, JSP Standard Tag Library http://www.jstlbook.com (coming this spring from Manning Publications) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: passing references to tags using XML syntax
The %= ... % syntax is intended only for custom actions (and those standard-action attributes that support it). Inserting dynamic text into an HTML tag's attribute is just like inserting dynamic text into arbitrary static, template text. The problem is that under the XML syntax, you can't simply include one tag within another; the tags are coordinate in the XML syntax, unlike in the JSP syntax where one tag is recognized by the language (JSP) and the other isn't. To get around the problem in the XML syntax, you need to treat the HTML tag explicitly as template text. You can, for instance, use jsp:text with the appropriate entity references, as follows: jsp:text lt;a href=/jsp:textjsp:expressionmyURL/jsp:expressionjsp:textgt; /jsp:text (Note how I've been careful about whitespace.) Alternatively, if escaping characters gets cumbersome, you can always use an XML CDATA block. -- Shawn Bayern Author, JSP Standard Tag Library http://www.jstlbook.com (coming this spring from Manning Publications) On Thu, 14 Feb 2002, August Gresens wrote: The solution from the spec worked for the use with the input taglib. I'm now having a problem with standard HTML tags, when I want to include values I have declared elsewhere in the code. For example jsp:declaration String myURL = http://www.foo.com; ; /jsp:declaration Later in the page, I want to reference this value in constructing a URL: a href=%= myURL%click here/a in the output, the substitution is not made. The output is printed exactly as it is in the JSP page. I am doing something wrong here? Thanks, August On Wednesday, February 13, 2002, at 03:25 PM, Shawn Bayern wrote: On Wed, 13 Feb 2002, August Gresens wrote: options=%= o % / With XML syntax, this won't work because the and characters are illegal in XML with attributes, and JSP chokes while attempting to parse it. Does anyone know how to do this? Is there a new syntax for the XML syntax to indicate to JSP that a reference instead of a value is being passed (like XSLT's $ operator). Yes: %= rtexprvalye %. Section 5.3.11 of the JSP specification provides the full info: Request-time attribute expressions are of the form %= expression %. Although this syntax is consistent with the syntax used elsewhere in a JSP page, it is not a legal XML syntax. The XML mapping for these expressions is into values of the form %= expression %, where the JSP specification quoting convention has been converted to the XML quoting convention. Also, it's worthwhile pointing out that since JSTL's (and JSP 1.3's likely) expression language will not rely on the rtexprvalue syntax, it won't need this sort of escaping. In other words, your c:forEach tag should work similarly under the familiar and XML views of the page. -- Shawn Bayern Author, JSP Standard Tag Library http://www.jstlbook.com (coming soon from Manning Publications) -- To unsubscribe, e-mail: mailto:taglibs-user- [EMAIL PROTECTED] For additional commands, e-mail: mailto:taglibs-user- [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: Where does $customers get defined? (Plus some suggestions...)
On Wed, 13 Feb 2002, Howard Treisman wrote: The standard-examples.war file provided with the distribution is excellent. However, I had a lot of difficulty understanding ~where~ the value $customers comes from in many of the examples. For example: c:forEach var=customer items=$customers Where does that pesky $customers come from? They come from a listener that initializes data when the context starts up. The listener is defined in the standard-examples application's web.xml file: listener listener-class org.apache.taglibs.standard.examples.startup.Init /listener-class /listener The source code to this class is located under the examples/src directory; it's compiled as part of the build process and included under WEB-INF/classes in the destination 'examples' application. My questions/suggestions are: 1. Question: Am I vaguely correct? Yes! Just to make sure my description was clear, from the root of the 'standard' directory, the path to the source to the 'Init' class is as follows: examples/src/org/apache/taglibs/jsptl/examples/startup/Init.java 2. Suggestion: Please provide more documentation on the basics of the expression language, especially the $ symbol and what it means and how it works. (There seems to be quite a bit of confusion about this elsewhere on the mailing list.) Yeah, I agree. Unfortunately, since the early-access release doesn't specify or use a single expression language (but instead a pluggable collection of them for the purposes of experimentation), we weren't able to document a single one thoroughly. Even the special meaning associated with the '$' symbol is up to the individual languages. 3. Suggestion: Please provide the corresponding .jar files for all the .class files in the standard-examples.war. You mean the individual classes tied to the standard-examples application? I guess we could do that, but I wanted to make sure that they didn't get confused for generally applicable, reusable JARs. All JARs that you'd likely want to use in your own applications are made available as JARs. Did you have a specific suggestion about which classes might be more usefully packaged than we're giving them credit for? 4. Question: I have been unable to find a reference for the web.xml file, especially the listener tag - can someone please point me at it. The web.xml file is described in chapter 13 (Deployment Descriptor) of the Servlet 2.3 specification, available from java.sun.com. The listener tag represents a concept introduced with version 2.3 of the Servlet specification. Hope that helps, -- Shawn Bayern Author, JSP Standard Tag Library http://www.jstlbook.com (coming soon from Manning Publications) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: use of tags within scriptlets?
On Thu, 7 Feb 2002, Lomvardias, Christopher wrote: Hi, I'm just getting started working with some of the Jakarta Taglibs. One thing I'm interested in doing is something like this. Let's say I've run a query and returned a result and want to place the value of a column into local variable. This obviously bombs. How would I do this? Not as such. :-) You have a few choices. You can manually invoke the tag handler class and call its methods (doStartTag(), doEndTag(), and so on), capturing its output manually. This is somewhat tedious and error prone, and I wouldn't recommend it. Alternatively, you can cause the tag to expose a scripting variable -- that is, a variable accessible to scriptlet code. The tag needs to have this feature built in, however (by convention, using the id attribute) so that you can write code like this: custom:tag id=foo / %= foo % % methodCall(foo); % DBTags's sql:getColumn tag, and the standard JSTL database tags, don't support scripting variables; overall, scripting code (Java within JSP pages) is being de-emphasized. Instead, they expose outputs as scoped variables that you can access with pageContext.findAttribute(). DBTags's sql:getColumn has a to attribute that names the scoped attribute exported: sql:getColumn colName=fname to=fname / %= pageContext.findAttribute(fname); % The JSP Standard Tag Library (JSTL) introduces the convention of using an attribute named 'var' to expose scoped variables, as c:set var=foo Foo! /c:set // use 'foo' here For more information on what replaces scripting variables and Java code directly in JSP pages, you might be interested in an article I've recently written on the subject. You can get to it from the front page of Manning Publications's web site at http://www.manning.com Hope that helps explain things, -- Shawn Bayern Author, JSP Standard Tag Library (upcoming, Manning) http://jstlbook.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [standard] Newbie: How to extend the examples?
Hi Eric,
It actually looks like what you've done is correct. Make sure that you've
recomppiled the org.apache.taglibs.standard.examples.startup.Init class
and that the container is noticing your changes. For instance, add some
logging to that class and see if your message is printed to the log.
(I note that the final line you added, while sufficient to expose a scoped
attribute to your JSP page and thus to JSP, doesn't end with a ;, which
might indicate you didn't recompile the class.)
Hope that helps,
--
Shawn Bayern
Author of JSP Standard Tag Libary (Manning, upcoming) http://jstlbook.com
On Fri, 1 Feb 2002 [EMAIL PROTECTED] wrote:
Hi
I'm new to JSTL and not quite new to Java. I think JSTL is the best thing
since sliced bread :-) but I'm having a problem. Probably this is a very
dumb question, but anyway...
(I tried the examples and they all work)
All I'm trying to do is set up a new iterator. Thus, I modify
org.apache.taglibs.standard.examples.startup.Init by copying
/**
* Array of Objects (String)
*/
String[] stringArray = new String[] {
A first string,
La deuxieme string,
Ella troisiemo stringo,
};
sce.getServletContext().setAttribute(stringArray, stringArray);
and modifying it:
/**
* Array of Objects (String)
*/
String[] stringArray = new String[] {
A first string,
La deuxieme string,
Ella troisiemo stringo,
};
sce.getServletContext().setAttribute(stringArray, stringArray);
/**
* Array of Objects (String)
*/
String[] storyArray = new String[] {
A first string,
La deuxieme string,
Ella troisiemo stringo,
};
sce.getServletContext().setAttribute(storyArray, storyArray)
Then I modify DataTypes.jsp:
h4Array of objects (String)/h4
c:forEach var=string items=$stringArray
c:expr value=$string/br
/c:forEach
c:forEach var=story items=$storyArray
c:expr value=$story/br
/c:forEach
I stop and restart Tomcat and open DataTypes.jsp in the browser, but I just
get the following error:
ReferenceError: storyArray is not defined.
at org.mozilla.javascript.NativeGlobal.constructError(Unknown
Source)
at org.mozilla.javascript.NativeGlobal.constructError(Unknown
Source)
at org.mozilla.javascript.ScriptRuntime.name(Unknown Source)
at org.mozilla.javascript.gen.c11.call(:0)
at org.mozilla.javascript.gen.c11.exec()
at org.mozilla.javascript.Context.evaluateReader(Unknown Source)
at org.mozilla.javascript.Context.evaluateString(Unknown Source)
at
org.apache.taglibs.standard.lang.javascript.JavascriptExpressionEvaluator.ev
aluate(JavascriptExpressionEvaluator.java:115)
at
org.apache.taglibs.standard.lang.support.ExpressionEvaluatorManager.evaluate
(ExpressionEvaluatorManager.java:200)
at
org.apache.taglibs.standard.tag.el.core.ForEachTag.evaluateExpressions(ForEa
chTag.java:196)
at
org.apache.taglibs.standard.tag.el.core.ForEachTag.doStartTag(ForEachTag.jav
a:107)
at org.apache.jsp.DataTypes$jsp._jspService(DataTypes$jsp.java:201)
at
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:107)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
etc. etc.
Probably I'm just being naive, but how exactly do you define a new object to
be used in JSTL? I couldn't find any further reference to the existing
stringArray in the source...
Best regards,
Eric
swissinfo/Swiss Radio International
Eric Lewis
IT Engineering
Giacomettistrasse 1
CH-3000 Berne 15
Phone:++41 31 350 95 42
Fax: ++41 31 350 99 40
mailto:[EMAIL PROTECTED]
Switzerland is everywhere. Stay connected!
http://www.swissinfo.org
http://mobile.swissinfo.org
http:/wap.swissinfo.org
SRG SSR idée suisse
--
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: Hello, and need help
On Wed, 30 Jan 2002, Brady Moritz wrote: This jstl looks a bit interesting, was not really aware of it. Will this do away with the Jakarta project or will they remain parallel projects? JSTL is the JSP Standard Tag Library. It's essentially a standard add-on to JSP. Its reference implementation is distributed through the Jakarta Taglibs project. For more information on JSTL, I've posted an article at Manning's web site describing its role and future: http://www.manning.com Best, -- Shawn Bayern Author, JSP Standard Tag Library (Manning, upcoming) http://jstlbook.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Accessing session scoped variables from exppression languageinthe standard taglib: Howto?
On Tue, 29 Jan 2002, Wolfgang Röckelein wrote: BTW: Where should we provide input to the EL discussion? Is this discussion public? It can be discussed informally here. More formally, the subject has now been taken up by the JSR-152 group, so I should defer to Eduardo Pelegri-Llopart and Mark Roth (the spec leads) in describing how they're prefer community feedback on the EL. My guess is that the [EMAIL PROTECTED] feedback alias would work. Does the ECMA implementation support all scopes that SPEL supports: page, request, session, app, header, param, paramvalues? No, I think the current ECMAScript implementatino supports only scoped attributes (page, request, session, and app). The final EL will most likely support more than this, though. Regarding the question regarding and, or, not on http://jakarta.apache.org/taglibs/doc/standard-doc/spel/spel.html: I think this depends on the goal of the JSTL in whole: Should there still be normal to use Java code in JSP or is the aim that most Java code should be replaced with tag lib usage? If the later is the goal, the EL needs not only boolean operators but eg math and string operators, too. Excellent point; I agree with this too. My sense is that there's consensus on this issue from others debating the topic, too. BTW: Are you sure that the core-rt version of if works? I never succeeded in getting the body evaluated, even with test=1==1... It works for me: crt:if test=%= 1==1 % 1 does indeed equal 1, interestingly enough /crt:if If you're still having trouble with it, let us know; please show the entire JSP page and include info about what container you're using. Best, -- Shawn Bayern Author, JSP Standard Tag Library (Manning, upcoming) http://jstlbook.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Standard eval tag
On Sun, 27 Jan 2002 [EMAIL PROTECTED] wrote: How do I put the result of the tag into the method? Without having to create a tag for Language. My suggested solution would be a tag which places its body into a named variable. So: standard:eval var=namestore:get jdo=person.name//standard:eval % out.write(Language.translateToSwahili(context.get(name))); % Or some such... Unless I'm misunderstanding your request, you can do this with c:set -- c:set var=name store:get ... / /c:set Shawn -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Standard expression language question
Hi Pedro, The answer will depend on the final expression language. For now, the behavior you note is caused by the experimental 'ECMAScript' expression language included with EA3; it performs concatenation on values it sees as Strings. In this experimental language, you can work around the problem by explicitly parsing values as numeric, as follows: c:set var=foo1/c:set c:set var=foo value=$1 + parseInt(foo)/ c:expr value=$foo/ This will print 2. (By the way, a note of caution is in order: all of EA3 is experimental and subject to change in the upcoming, final standard. Don't get too used to clever tricks and workarounds that are EA3-specific!) -- Shawn Bayern JSTL reference-implementation lead Author, JSP Standard Tag Library (Manning,upcoming) http://jstlbook.com On Mon, 28 Jan 2002, Pedro Diaz wrote: Hi all. After executing the next two lines c:set var=foo1/c:set c:set var=foo value=$foo + 1/ the value of foo is 11 Is there a way to get that the value of foo be 2 using expression language? Thanks in advance. Pedro. -- 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: Accessing session scoped variables from exppression language inthe standard taglib: Howto?
On Mon, 28 Jan 2002, Wolfgang Röckelein wrote: how do I access session scoped variables from expression language in the standard taglib library? The answer depends on the actual expression language you use. EA3 doesn't define just a single expression language; instead, it lets you plug in various experimental ones. The expert group decided on this approach for the early-access RI to encourage testing and feedback. The final version of JSTL will use a stable, easy-to-use expression language. Having said that, in JSTL EA3 by default, you can access session-scoped attributes simply by using their names. To access 'foo' in session scope, for instance, just use the following expression: $foo Technically, JSP's scopes represent a single namespace, so if you have 'foo' in session scope, you couldn't have it in request or application scope as well. However, in practice, this isn't widely enforced, so make sure you don't have a 'foo' attribute in page or request scope before using the expression above (as these two scopes are higher 'priority' than session). And, btw, what is with request scoped, apllication scoped, etc. variables? JSP supports multiple scopes to give page authors more control over the lifecycle of their data. For example, request scope applies to all pages used to service the current request (e.g., through c:import or jsp:forward tags). Application scope applies to the whole application. In EA3's default experimental langauge, all scopes are accessed using the same syntax: $name. EA3 also comes with a language called SPEL that lets you access scopes specifically: $session:foo $request:foo and so on. -- Shawn Bayern JSTL reference-implementation lead Author, JSP Standard Tag Library (Manning,upcoming) http://jstlbook.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: x:tranform and no stylesheet
On Mon, 28 Jan 2002, Matt Raible wrote: Is it possible to not specify a stylesheet for the x:transform tag - so it renders with the browsers default stylesheet? Hi Matt. I might be misunderstanding the question, but if you want the browser to render a document, why transform it on the server with x:transform? And if you're going to transform it with x:transform, what mechanism is in place for the server to learn of the browser's stylesheet? -- Shawn Bayern JSTL reference-implementation lead Author, JSP Standard Tag Library (Manning, upcoming) http://jstlbook.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tags and error 404
What JSP container are you using? From what you say, it sounds as if the container is mis-diagnosing the problem and returning a simple 404 instead of any useful information. I believe that a JSP container can, when no errorPage is defined, handle errors and exceptions in an implementation-defined manner. If you use an errorPage, however, the implementation must fall in line with standard behavior. Therefore, if you catch the exception with an errorPage (see the %@ page % directive), you should be able to use the implicit object 'exception' to get more information. Shawn On Wed, 16 Jan 2002, mbutu zezezeko wrote: Hi, Does anyone know why i get Error 404--Not Found when there is a small error in for example the query. I get no stacktrace either so it's hard/impossible to debug. I have the same problem with i18n tags when a key is not found. br, mz database:connection id=connection jndiName=somePool/ database:statement id=statement conn=connection database:query SELECT * FROM logging /database:query database:resultSet id=result tr tddatabase:getColumn position=1//td tddatabase:getColumn position=2//td /tr /database:resultSet /database:statement _ Chat with friends online, try MSN Messenger: http://messenger.msn.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]
Standard taglib's c:forEach and Resin
On Tue, 15 Jan 2002, Vianen, Jeroen van wrote: I downloaded the 14 January snapshot and saw that this problem has been fixed in current sources after Shawn Bayern's bug report. Thanks for pointing this out. According to Resin's bug tracker, Scott Ferguson responded almost immediately with the following comment: Changed to test for TagSupport and BodyTagSupport explicitly This should fix the problem with c:forEach and Resin. Shawn -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: JSPTL EA3 - x:transform works, but error in tomcat
Are you sure that html:html is producing a well-formed XML document (i.e., with a single root element)? Shawn On Mon, 14 Jan 2002, Matt Raible wrote: I am trying to use the x:transform tag to render the following page (code pasted below). The transformation works (displayed in browser correctly), but the following error shows in tomcat's log: SystemId Unknown; Line 55; Column -1; Can not load requested doc: Document root element is missing. Code from page - %@ page 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=http://java.sun.com/jstl/ea/core; prefix=c % %@ taglib uri=http://java.sun.com/jstl/ea/xml; prefix=x % c:import url=/styles/xsl-xhtml.jsp var=xslt/ x:transform xslt=$xslt html:html locale=true xhtml=true properties authorMatt Raible/author titlebean:message key=index.title//title headingbean:message key=index.heading//heading /properties body !-- TODO: Remove ALL HTML -- logic:notPresent name=database scope=application span class=error ERROR: User database not loaded -- check servlet container logs for error messages. /span hr / /logic:notPresent logic:notPresent name=org.apache.struts.action.MESSAGE scope=application span class=error ERROR: Application resources not loaded -- check servlet container logs for error messages. /span /logic:notPresent ul lihtml:link page=/do/editRegistration?action=Createbean:message key=index.registration//html:link/li lihtml:link page=/logon.jspbean:message key=index.logon//html:link/li /ul html:link page=/do/tour bean:message key=index.tour/ /html:link /body /html:html /x:transform -- 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: [standard] Does not work in Resin
On Sun, 13 Jan 2002, Alice K wrote: The EA3 does not work on Resin 2.0 and over. The EA1 is working correctly. Okay - I finally got a chance to look at this problem closely. The issue is, as I suspected all along, a bug in Resin. However, I didn't, in my wildest dreams, guess what the actual Resin bug would be. In fact, I thought the problem would result from a simple failure to detect IterationTag and test for doAfterBody(). Indeed, on first glance, this looked like the culprit, for the Java code that Resin generated didn't include any iterative construct (e.g., a do ... while or while loop) for c:forEach. However, not being able to replicate the problem with a simple, non-JSTL class, I tracked the issue to its source: a method in Resin's JSP translator that determines, for standard methods like doAfterBody(), whether the implementing class is part of the javax.servlet.jsp package. Thus, in short, we fail because we're a standard! :-) (In case you're interested, Resin uses this information -- wildly erroneously, in my opinion! -- as a heuristic in order to determine whether the tag handler at hand implemented or inherited a method. In my opinion, Resin shouldn't rely on this information in the first place; it uses the concept of a default tag-extension API method, which it really ought not need to use. But putting that point of design philosophy aside, the important bug is that Resin acquires this information in a problematic way: based on the package name of the declaring class.) I've submitted a bug report to the Resin folks. Thanks to everyone who raised this issue here. Shawn -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Réf. : Can not use JSTL on WebLogic 6.0 - PleaseAdvise
On Wed, 9 Jan 2002 [EMAIL PROTECTED] wrote: - it fails to deploy on WLS 6.1 SP1 (obscure Error deploying application . \config\mydomain\applications\standard-examples.war: java.lang.reflect.UndeclaredThrowableException) - it seems to work on WLS 6.1 SP2 (not tried every example, but the ones I tried worked perfectly) Thanks for the comments. Given this part of your message, I would suspect that SP2 fixes a compliance-related bug in WebLogic 6.1. Shawn -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Tags, Extra Info and scripting variables
On Tue, 8 Jan 2002, Bryan P. Glennon wrote:
Shawn -
Sometimes long-shots come through. The defining tag was inside an
html:form block. That brings up another question - I thought that the
variable would have page scope (and I need it to). Am I just
out-of-luck?
Maybe, but you can usually find a way around issues like this.
The scoped *attribute* does have page scope, but the scripting variable
has a lexical scope based on the Jave code to which the JSP page compiles.
So, the easiest thing to do (perhaps!) is expose (declare) the variable
earlier, and then set it with another tag later. (This is one thing the
declare parameter in VariableInfo's constructor is for.)
For instance, usage might look like this:
custom:declare varName=foo
html:form
custom:set varName=foo
/html:form
%=foo%%-- uses second value --%
Just to make sure what's going on is clear, the result Java code would
logically look like this:
String foo;
foo = pageContext.getAttribute(foo);
if (...) {
// block for html:form tag
foo = pageContext.getAttribute(foo); // custom:set
}
// here, 'foo' is declared from before, but has value from
// inner block
Hope that helps!
--
Shawn Bayern
Author, The JSP Standard Tag Library: http://www.jstlbook.com (upcoming)
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: tag sources
On Thu, 3 Jan 2002, Maciej Ko³odziej wrote: Where can I get sources of standard jsp tags, like jsp:forward? Standard JSP actions are implemented by code owned by the container; they are not imported from external code (at least not using a public standard mechanism), as custom actions can be. Check the code for Tomcat, for example, to see how actions like jsp:forward are handled. Shawn -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: standard taglibrary examples not working
As other users have pointed out, Resin seems to fail on the JSTL RI's iteration tag; I haven't yet had a chance to look into whether this is a Resin bug or not. If anyone who already has Resin set up would be interested in testing whether this bug occurs with any IterationTag or just with the JSTL RI's tag handlers, that would be very useful over the short term. Thanks! Shawn On Thu, 3 Jan 2002, Wim Bervoets wrote: Hello, This is the output I get from the http://localhost:8080/standard-examples/iterators/SimpleRange.jsp Simple Range Iteration 1 to 10 1 * That doesn't seem correct (should be displaying numbers from 1 to 10) I always only get the first element displayed. I'm using the latest nightly build from Resin 2.x and Standard tag library. Best regards, Wim -- 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: [standard] sql:update doc/behavior discrepancy
On Thu, 3 Jan 2002, Paul DuBois wrote: The documentation for sql:update indicates that the var attribute is optional, but I find that without it I get an error message that the TLD requires it. Adding var=dummy cures the problem, but should that be necessary? Hmm. The TLD doesn't show it to be required: tag-classorg.apache.taglibs.standard.tag.el.sql.UpdateTag/tag-class body-contentJSP/body-content description Executes the SQL update defined in its body or through the sql attribute. /description attribute namevar/name requiredfalse/required rtexprvaluefalse/rtexprvalue /attribute However, the tag handler did seem to assume it was set; I've fixed that, since I believe it was a bug. Are you sure the error message you got wasn't related to a NullPointerException that would have been thrown on an attempt to call pageContext.setAttribute(null, ...)? Shawn -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [standard] c:if accepts what expression types?
On Wed, 2 Jan 2002, Paul DuBois wrote:
What are the constraints on the type of expressions that may be used
with c:if?
The short answer is 'boolean' or 'Boolean.'
The somewhat longer answer is that for the rtexprvalue library, the only
permissible type is 'boolean'. For the EL library, the value must resolve
to a Boolean as far as the tag handler's concerned; it's up to the
expression language, not the tag handler, to convert boolean (e.g., a
boolean Bean property) to Boolean.
Assume that $x has the value 1: c:set var=x value=1/
This evaluates the body:
c:if test=$x == 1/true/c:if
This does not:
c:if test=1 == $x/true/c:if
So the test must begin with a variable?
Note that '$' does not begin a variable, but identifies an EL expression.
Don't confuse '$' with the Bourne shell (or Perl) variable-reference
operator. The attribute value 1 == $x represents the String literal
1 == $x; $x == 1 represents the EL expression x == 1. Thus,
$1 == x should work just fine.
Note that this syntax is certainly not beyond debate. At a conference
recently, a member of the audience in a presentation I was giving on JSTL
suggested that XSLT's '{}' syntax would be much clearer to adopt than
Unix's '$'. Do you think that if the syntax had been
c:if test={x == 1}
and
c:if test={1 == 1x
that this would have avoided the confusion? I'd personally be very
interested in any feedback you've got.
Also, it looks like you can test only *one* variable value. If I try
to compare two values like this:
c:if test=$var1 == $var2true/c:if
Then I get: ReferenceError: $var2 is not defined.
Same issue here; the 'var2' attribute is referenced as 'var2', not
'$var2'. ($var2 could be the name of an attribute in its own right; the
ReferenceError comes from findAttribute($var2) failing.
Is there a way to compare two variables directly from JSTL, if c:if
cannot? I'm using EA3.
$var1 == var2
$var2 == var1
P.S. Most of the /standard-doc/Conditionals_FunctionalDescription_1_EA1.html
page uses JSTL core tags in the examples with no c: tag prefix (e.g., when
rather than c:when).
Yeah, we have yet to decide how to consistently describe our actions, when
the prefixes are really just suggestions and not mandated in any context.
I'm facing the same problem with my JSTL book. I'm personally leaning
toward always using the suggested prefixes in writing.
Shawn
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [standard] sql:param doesn't accept a body
Thanks for the problem report, Paul. This was an error in the TLDs; the relevant tag handlers look okay. I've fixed the problem, and the change should show up in tonight's nightly build. Shawn On Wed, 2 Jan 2002, Paul DuBois wrote: The documentation for sql:param states that it can be used in either of the following ways: sql:param value=parameterValue/ or sql:param parameterValue /sql:param However, using the second form results in an error message: Body is supposed to be empty for sql:param. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
