Re: Serialising javax.servlet.jsp.jstl.sql.ResultImpl
On Tue, 16 Dec 2003, Kris Schneider wrote: Thanks for looking into it. To be honest, I'm surprised it took this long to surface ;-). As for whether Result should actually extend Serializable, I'm usually of the mind that an interface shouldn't extend Serializable and that it's an implementation detail. Consider the core collection interfaces and classes: neither Map nor SortedMap extend Serializable and AbstractMap doesn't implement it. TreeMap, however, does implement it. Another example would be the ResultSet and RowSet interfaces, neither of which extend Serializable. The important distinction here isn't between interface and implementation but between specification and implementation. Regardless whether an interface should typically be extended by an interface or implemented by a class (which I'll address in a moment), Pierre's concern here is that the enhancement request shouldn't be addressed by an implementation of the JSTL specification on its own. While I don't think it would strictly violate the JSTL specification for a JSTL implementation to have one of its classes (which implements a specified interface) implement another arbitrary interface, it would certainly be poor practice for users to rely on this nonstandard behavior (and thus probably irresponsible for an implementation to promote it). As for the specific point about whether interfaces should extend or implementations should implement, I don't think the analogies you raise are apposite: Map indeed doesn't extend Serializable, but this is only because there's no call for all implementations of Map to be Serializable. The JSTL specification could conceivable require that all implementations of a standard interface also implement Serializable, but the most elegant way for it to accomplish this is to have the standard interface extend Serializable itself. Indeed, this approach is very common: note the number of subinterfaces to Serializable (i.e., the number of interfaces that extend Serializable) in the J2SDK 1.4 API. Shawn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: break in c:forEach
On Fri, 17 Oct 2003, Balakrishnan, Vijay wrote:
I want to use a break in a c:forEach as follows:
c:forEach items=${lecContacts} var=lecContactFirst varStatus=status
c:choose
c:when test=${status.first}
c:set var=lecContactId value=${lecContactFirst}/
/c:when
c:otherwise
!-- break here How to do that ??--
/c:otherwise
/c:choose
/c:forEach
I don't want to use flag if that is possible.
Because such a break was impossible to implement on JSP 1.2, JSTL 1.0
doesn't implement it. (To my knowledge, there are no plans to implement
it in the future.) Note that in your example, it's not necessary;
${status.first} will be true for only the first element in your loop, so
it would be clearer just to turn the c:when tag into a c:if tag and be
done with it.
But in the general case, you'll need to use a flag.
--
Shawn Bayern
JSTL in Action http://www.jstlbook.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
JSTL in Action
Hi there (from law school)! :) As I take a break from reading about civil rights in California, I just wanted to point out that I just found out JSTL in Action is back in stock at Amazon.com. (Some people here had pointed out that it was sold out for a while, but Amazon's stock is now replenished.) Hope that helps, Shawn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Unable to find value using operator . (null)
On Sat, 23 Aug 2003, Rick Ross wrote:
I have a class called RTime. It has the following get methods (and no SET
methods):
public String getCrazy()
public String getUSTime()
public String getISOTime()
With these methods (and the rest of what you describe), you have the
following JavaBeans properties:
crazy
USTime
ISOTime
Your capitalization of multiple leading letters in the last two accessor
methods causes the JavaBeans introspector to preserve the capitalization
you use; the default pattern, however, is for getXxx() to refer to a
property named 'xxx', not 'Xxx'. (For more information, see the JavaBeans
specification.)
I've renamed the method a dozen times. Added a matching setter method,
renamed the class, added and removed other get methods ... nothing
changes the fact that it, and new methods, will not work..
Changing the method, and adding other classes, won't help. Just refer to
the property as ${foo.crazy}.
--
Shawn Bayern
JSTL in Action http://www.jstlbook.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: several messages
On Thu, 7 Aug 2003, Rick Roberts wrote: Dude! Amazon and BarnesAndNobel are out of JSTL in Action. They must be selling like hot-cakes :) Ha. I just noticed too, and I've talked with the publisher; I hear they'll be restocking them soon. -- Shawn Bayern JSTL in Action http://www.jstlbook.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Getting default data source into JSP
On Mon, 28 Jul 2003, Michael Duffy wrote: I'm thick - how do I refer to it in the JSP? Shawn Bayern's JSTL In Action says that the constant is Config.SQL_DATA_SOURCE, and its variable name is javax.servlet.jsp.jstl.sql.dataSource. What scope is this variable in, and how can I get at it in my JSP? It sounds like I'll have to use the rt library [...] There is indeed a standard constant and a standard name for the context-initialization parameter, but the data is not necessarily saved in a particular scope with a particular name. (If I remember correctly, this was designed to give greater flexibility to implementations and future versions of JSTL.) To retrieve the data, you'll want to use the Config class itself, which abstracts the variables for programmers. I can't think of any way to retrieve the information in a standard fashion using just the 'el' tags. -- Shawn Bayern JSTL in Action http://www.jstlbook.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: several messages
On Fri, 25 Jul 2003, Thomas Martin wrote: Reading tech books is a good way to ruin a good cigar. Hey! Parts of my book should go quite well with a cigar (though I can't honestly say that was the design goal). :-) On Fri, 25 Jul 2003 [EMAIL PROTECTED] wrote: I much prefer Shawn's new book, JSTL Inaction, written after he took up Zen last year. Indeed. Check out JSTL at Rest, too... Shawn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta Taglibs Installation
On Mon, 30 Jun 2003, [gb2312] guo yingshou wrote: If it is *mandatory*,why the web-app.dtd still specifiy an optional taglib element?Just for backward compatibility? That's part of it, and it's also necessary for cases where a tag library doesn't package its JAR in the format necessary for it to work. Note that it's mandatory for the container to support it; it's not mandatory for a taglib author to deploy his or her libraries in this fashion (though it's probably a good idea in all cases). -- Shawn Bayern JSTL in Action http://www.jstlbook.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta Taglibs Installation
On Sun, 29 Jun 2003, Michael Duffy wrote: Actually, step 3. is unnecessary. When you create the JAR file for your handler, the TLD file goes inside it. It's already got the URI string you should use in your JSP. When the JSP compiler goes looking for your TLD, it'll find it in the JAR because it's already in the CLASSPATH. Indeed, under JSP 1.2, the taglib element is unnecessary. As for duplicating the JAR files for each application, it's simply the cost -- and an exceedingly minor one in any reasonable environment -- of appropriate architecture. The advantages of including JAR files with an individual application include - a clear statement of the dependencies of the application and the ability to easily WAR it up and redeploy elsewhere - automatic detection of the JAR files' taglibs - isolation of 'static' data from other applications because a classloader specific to the web application loads the JAR files' classes; this can be important for security and for troubleshooting Shawn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta Taglibs Installation
On Mon, 30 Jun 2003, [gb2312] guo yingshou wrote: Are you sure it works on all j2ee complaint servlet engine? The behavior is mandated by sections 7.2.1 and 7.3.1 of the JSP 1.2 specification, so all compliant containers support it; if a product claiming compliance doesn't support it, then it's a bug. Shawn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Auto commit in Jakarta taglib?
Ah - I just realized you were using DBTags, not JSTL. If you're using a JSP 1.2 container, you'll probably want to switch to JSTL anyway. -- Shawn Bayern JSTL in Action http://www.manning.com/bayern On Mon, 16 Jun 2003, Roland Dong wrote: I have some programs which uses pre-jstl jakarta taglib. I want to have the query commit only if there is no errors. However, I could not find in tags for setting autocommit. Tried to add %conn.setAutoCommit(false);% but that doesn't work. So I am wondering if there is a workaround other than rewriting everything using other tag library(I know struts has it). Thanks in advance. RD The is a code example I used to test auto commit. = %-- Taglib Directives --% [EMAIL PROTECTED] uri=http://database.cait.org/dbtags; prefix=sql % -database connection--% %@ include file=../includes/dbConnection.jsp% sql:statement id=stmt conn=conn sql:query INSERT INTO school VALUES ( '666', 'rd', 'street1', 'city1', 'county1', 'state1', 'zip1', 'phone1' ) /sql:query sql:execute / sql:query INSERT INTO school1 VALUES ( '888', 'rd', 'street1', 'city1', 'county1', 'state1', 'zip1', 'phone1' ) /sql:query sql:execute / /sql:statement OK! %-- Close database connection --% sql:closeConnection conn=conn/ === - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Document root element is missing
On Wed, 11 Jun 2003, Jim Kennedy wrote:
x:parse xml=xmldoc_string var=document/
This tag will attempt to parse the literal string xmldoc_string, which
explains the Document root element is missing message. Instead, you'll
need to refer to this string (assuming it's stored as a scoped variable or
something similar) with an EL expression. In other words, if you've
called it 'xmldoc_string' in one of the scopes, then
x:parse xml=${xmldoc_string} var=document/
should work.
--
Shawn Bayern
JSTL in Action http://www.manning.com/bayern
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Example use of java.servlet.jsp.jstl.sql.dataSource?
On Fri, 6 Jun 2003, Michael Duffy wrote: In Chapter 14 of Shawn Bayern's JSTL In Action, he talks about setting up a default data source for JSTL. He shows how to add context-param tags to the web.xml deployment descriptor on page 352, and below that says the parameter name for the default data source is javax.servlet.jsp.jstl.sql.dataSource. But he doesn't show an example of how to use it in the JSP. In the JSP pages, JSTL tags will automatically sense the default DataSource that you have established and will acquire connections from it as necessary. When you set a default, you don't need to use the sql:setDataSource tag at all; this tag is useful only in cases where you haven't established (or want to override) the default. -- Shawn Bayern JSTL in Action http://www.manning.com/bayern - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: tag forEach
On 3 Jun 2003, Dave Newton wrote: One way around this might be just to say that if you want your tags to play nice with JSTL tags (break in particular) that it should implement J. Random Interface (or whatever) that deals with this parent tag communication issue. But then page authors would need to know which tags they could use and which they couldn't use around break. The problem isn't how to support tag developers; if that were the issue, we could already give them guidelines on how to interoperate with JSTL (in this case, they'd need to rethrow the exception if they caught it). Instead, the goal is to simplify things for page authors. -- Shawn Bayern JSTL in Action http://www.manning.com/bayern - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Custom tags outputting a JSTL tag
On Wed, 28 May 2003, Danilo Luiz Rheinheimer wrote:
I have a custom tag, and I want to output a JSTL tag on it.
But this new tag is not processed.
Like this :
public int doStartTag() throws JspException {
try {
JspWriter out = pageContext.getOut();
out.println(c:out value=\y\/);
}
catch (IOException ex) {
}
return EVAL_BODY_INCLUDE;
}
Any help ?
This can't easily be done because the JSP container won't interpret your
output as tags. You could walk through the various steps that the JSP
container performs to invoke c:out -- e.g., instantiate a handler, call
the accessors, call doStartTag(), and so forth -- but that's
extraordinarily tedious.
An easier solution might be to use the RequestDispatcher to include a page
that contains the tag you want to include, parameterized by request
attributes. This leads to a better design anyway, where output stays the
responsibility of JSP pages.
--
Shawn Bayern
JSTL in Action http://www.manning.com/bayern
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Evaluating BodyContent
JSP 2.0 (for which standard Tomcat 5.0 is a compliant container) shifts
the responsibility of evaluating EL expressions to the container, not
individual tag handlers. If you're writing an application for JSP 1.2,
you could theoretically use our ExpressionEvaluatorManager to parse
expressions from anywhere, including BodyContent; simply ignore the
arguments associated with tag attributes.
Note that without JSP 2.0's support, retrieving expressions from
BodyContent and parsing them at doEndTag() (or some other fixed point) can
be extraordinarily confusing to users. Consider the following situation:
my:tag
${a}
c:set var=a value=${...} /
/my:tag
The user will probably expect ${a} to evaluate to its original value, but
if the tag's only opportunity to read and parse the content comes within
doEndTag(), ${a}'s evaluation will be affected by the c:set that occurs
*after* its presence in the page.
--
Shawn Bayern
JSTL in Action http://www.manning.com/bayern
On Fri, 21 Mar 2003, Tim Kettering wrote:
If I understand correctly, a JSP 2.0 container will let you use EL 2.0 expressions
anywhere in the jsp body without having to use the JSTL tags. I also believe that
Tomcat 5 is a JSP 2.0 container, and that support may already be there, I have no
idea though. Someone else may be able to answer that better.
-tim
On Friday, March 21, 2003, at 10:21AM, James Smith [EMAIL PROTECTED] wrote:
I'm writing a custom tag where I would like to, if possible, evaluate the EL
expressions that may be present within the tag's BodyContent. The
ExpressionEvaluatorManager seems to need EL expressions to be tied to an
attribute of the tag. Is it possible to evaluate the BodyContent? If so,
how? If not, will this issue be resolved in JSP 2.0? Thanks much,
James Smith
Developer, Treistman Center
College of Fine Arts, University of Arizona
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Evaluating BodyContent
On 21 Mar 2003, Dave Newton wrote:
So... to me this implies that JSP 2.0 is moving closer to something
like Velocity and focusing less on custom tags. Is this a correct
assessment or is there more to the 2.0 custom tags that I don't know
about? (I admit I haven't read any specs, so feel free to give me a
hearty RTFM :)
I thought one of the points of JSP was to keep content/scripting
looking XML/HTML-ish for the benefit of page designers.
The only change is that expressions will be promoted to the level of
scripting expressions in order to simplify page syntax; the focus hasn't
changed. In other words, instead of
%= pageContext.findAttribute(foo) %
you'd simply write
${foo}
in JSP 2.0.
--
Shawn Bayern
JSTL in Action http://www.manning.com/bayern
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Evaluating BodyContent
On 21 Mar 2003, Dave Newton wrote:
I guess my curiosity just comes from the apparent abandonment of the
c:out.../ tag in favor of the obviously simpler EL expressions that
look like previously-existing solutions is all.
I'm not complaining; it's better from the brevity-standpoint, it's
just interesting that it moves away from what I thought was one of the
main points of JSP which was to provide an X/HTML-looking way of
accessing things put into scope by the back end of things.
I see what you're saying, but XML-looking is vague and not particularly
a target. The advantage of ${foo} to %= foo % is that it can be used in
the middle of otherwise well-formed XML documents; JSP continues to
provide an XML syntax. In fact, ${foo} is more compatible with XML than
c:out value=${foo} / in cases where you want to use the variable in
another tag.
--
Shawn Bayern
JSTL in Action http://www.manning.com/bayern
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Evaluating BodyContent
On 21 Mar 2003, Dave Newton wrote:
Hmm, that's true about the well-formed comment. If one of the goals
(WAS one of the goals?) was to remove scriptlets, though, isn't the
${foo} just some syntactic sugar around a %=..%?
Honestly, I wasn't trying to start anything :D
No, these are all good questions. One of the goals was indeed to remove
scriptlets. EL expressions improve upon them in two important ways:
- As I said before, the syntax is compatible with well-formed XML,
and it's shorter and more convenient for page authors.
- Expressions, unlike Java, are limited in function; they are only
used to retrieve values from a handful of specific locations, not
to call open-ended Java code.
--
Shawn Bayern
JSTL in Action http://www.manning.com/bayern
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Q] Will the *REAL* JSTL taglib documentation please stand up
On Thu, 20 Mar 2003, Jeff Smith wrote: I must be drunk, but I don't remember the drinking. (A sure sign that I *HAVE* been drinking :-) I am trying to find the tag documentation for JSTL (in particular the x stuff). I assumed that I would find a page, much like the tag docs for other taglibs. But all the links I find keep leading me around in circles, without actually listing the various tag commands, their attributes etc. Can somebody point me to a non-circular reference? The only authoritative reference for JSTL is the specification itself, available from http://java.sun.com/products/jstl. That page also has an appendix from my book that lists tags and attributes in a concise form. -- Shawn Bayern JSTL in Action http://www.manning.com/bayern - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Dynamic XPath Expression in JSTL
On Thu, 20 Mar 2003, Peter Giesin wrote: c:set var=foo value=/a/b[1]/ x:parse xml=some-xml-source var=xml/ x:out select=$xml/a/b[1]/ I would like to define the x:out statement to use the foo variable instead of the hard-coded xpath. Something like this: x:out select=$xml/$foo/ I have read through the spec and various other docs, but just cannot seem to get this working. If some one could help point me in the right direction I would greatly appreciate it. You can use XPath variables in XPath expressions within JSTL tags, but the syntax you're using isn't right. A variable evaluates to a value; it does not get string-interpolated into the text of your message. The expression you're looking for wouldn't be $xml/$foo but $xml/*[name()=$foo] or something similar. Shawn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSTL c:out rewrites html tags
On Mon, 10 Mar 2003, Hanasaki JiJi wrote: The JSTL taglibs (c:out) re-write html tags into GT so the actual text prints out. Is there any way to disable this? Yes, the escapeXml=false attribute of the c:out tag disables this behavior. -- Shawn Bayern JSTL in Action http://www.manning.com/bayern - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSTL c:out rewrites html tags
On Mon, 10 Mar 2003, Hanasaki JiJi wrote:
Thanks to Brian and Shawn! anyone know of a lib that will perfrom the
escXML on a String?
goal:
take in input string that may / maynot have HTML tags
zap the html tags or turn them to pure text ala LT
You can use c:out wrapped by c:set to do this, as in
c:set var=safeStringWithNoBrackets
c:out value=${mayContainHtmlOrMayNot} /
/c:set
%-- modify string --%
c:out value=${safeStringWithNoBrackets} escapeXml=false /
--
Shawn Bayern
JSTL in Action http://www.manning.com/bayern
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Dynamically built select statements (SQL)
On Mon, 3 Mar 2003, David Goodenough wrote:
sql:query
SELECT dno, action, destination, quantity, updated FROM load
WHERE c:out value=${where} /
/sql:query
When I try to run this I get an SQL exception
(javax.servlet.ServletException) :-
SELECT dno, action, due, destination, quantity, updated FROM load
WHERE area = 'NW'
ORDER BY due DESC FOR READ ONLY
: ERROR: parser: parse error at or near NW
The c:out tag by default escapes quotation marks, as they are XML
metacharacters. Use the escapeXml=false attribute to get around your
problem. (The problem would show up more clearly if you looked at the raw
HTML source of the page that's giving you this error message.)
--
Shawn Bayern
JSTL in Action http://www.manning.com/bayern
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Dynamically built select statements (SQL)
On Mon, 3 Mar 2003, David Goodenough wrote:
Now for the next one. I am trying to use the SQL resultset method
isLimitedByMaxRows. I tried c:if
test=${result.isLimitedByMaxRows} but that got reject with unable
to get value of ... with operator ., so I tried
result.limitedByMaxRows and that got the same. Presumably it is
looking for a get method, how do I access an is method?
${result.limitedByMaxRows} is correct; are you sure it produced an error?
--
Shawn Bayern
JSTL in Action http://www.manning.com/bayern
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: 1.03 Change List?
On Wed, 26 Feb 2003, Hunter Hillegas wrote: Any place where there is a list of changes? Sure. It's linked (as Release Notes) off of the Standard Taglib Documentation on the main page for the Standard Taglib at Jakarta Taglibs. The direct URL for the revision history is http://jakarta.apache.org/taglibs/doc/standard-doc/ReleaseNotes.html Shawn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Benefits of using taglibs...
On Wed, 19 Feb 2003, Ciramella, EJ wrote: My company has ~500 jsps - all of which are scriptlet heavy. I want to propose a change to using taglibs (either custom or directly from the taglib project). What can I site as the benefits? I'm hoping to find a web page or document or something that clearly states some sort of performance increase. Currently, it takes a REALLY long time just to load the login page (which has large scriptlets embedded and it's imports also are 90% scriptlet). I'm guessing that if these things were compiled classes in side a taglib, this would shorten load time and lessen the need to precompile the jsp's. Thanks in advance. The benefits of tag libraries are primarily organizational. You're unlikely to notice a performance improvement when switching from scriptlets to tag libraries; your scriptlet code is being compiled into servlets before it's run. -- Shawn Bayern JSTL in Action http://www.manning.com/bayern - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Starting
On Wed, 19 Feb 2003, Scott Taylor wrote: I have played around with some code examples and am interested in creating my own web sites using JSP, Servlets and JDBC from scratch. I don't wish to be a guru, just someone that could knock together a reasonably simple web app in a day or so. (like an online client database, or online consultant timesheet system which you use forms to enter and search.) Could I learn just tags, struts or Maverick without getting too much into Java code? You might find that you can get pretty far with JSTL. In fact, JSTL in Action has lots of information for people in your situation; I had sort of hoped there would be more people like you. :-) -- Shawn Bayern JSTL in Action http://www.manning.com/bayern - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Benefits of using taglibs...
On Wed, 19 Feb 2003, Ciramella, EJ wrote: Right, so if there are no/very little scriptlet code in the jsps and the tags are already classes, wouldn't this speed thing up at all? No, not at runtime; by the time your pages are accessed, they've already been compiled. (In other words, they're compiled only when they change.) -- Shawn Bayern JSTL in Action http://www.manning.com/bayern - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Starting
On Wed, 19 Feb 2003, Scott Taylor wrote: Do you have useful working examples in the book? Because I have found with other things like PHP/MySQL examples that it is easier to play around with a complete example than read several chapters of theory? Yeah, the major examples focus on your situation. I don't describe how to set up the database or its drivers, but there are a couple chapters with nothing but complete-application examples that use JSTL alone (not Java) to produce moderately complex web applications, like a message board, a survey application, and a web portal. They stretch JSTL as far as it can go in this respect; any larger applications would probably require Java. -- Shawn Bayern JSTL in Action http://www.manning.com/bayern - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSTL
On Tue, 18 Feb 2003, Jeff Corliss wrote: 1) There doesn't seem to be a varStatus attribute for the x:forEach tag like there is for the c:forEach tag. For the time being, I implemented one using c:set etc. (so I can have even/odd table row styles for a table being built from xml data), but it seems like there should be one. Will this be added in a future version? I believe it's in the pipeline of suggestions; there's probably no good reason not to add it. To record your specific need, you can mail [EMAIL PROTECTED] 2) Does anyone know if the Appendix PDF file (from the link on the java.sun.com jstl page) is redistributable (no licensing issues)? My publisher technically owns the copyright until the contract expires, but as it's author, I'm willing to go on record that there are no problems with redistributing it. 3) There are no WAR files in the 1.02 release (?), or did I download the wrong .zip? The version of 1.0.2 currently available from the download site has this problem; I vaguely remember fixing it long ago, but the oversight might still remain. Anyway, release 1.0.3 will be out soon; I had planned on releasing it this weekend but got sidetracked by a number of other things -- I expect to have it posted tonight or tomorrow. -- Shawn Bayern JSTL in Action http://www.manning.com/bayern - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tag List
Just as interesting historical background...
The terms model 1 and model 2 actually come from an old version of the
JSP specification that describes two models of web-application
development: the first model (model 1) sends requests directly to JSP
pages, whereas the second (model 2) sends requests to servlets, which
forward to JSP pages as necessary.
Model-View-Controller (MVC) is a design pattern that a model 2 web
application will often resemble.
Shawn
On Tue, 18 Feb 2003, Schnitzer, Jeff wrote:
So far the best explanation I have found of MVC aka Model-2 is on
Sun's site:
http://developer.java.sun.com/developer/onlineTraining/JSPIntro/contents
.html#JSPIntro4
Sun calls the pattern Model-2, but there is enough similarity to the
Smalltalk pattern that the term MVC has been (arguably
mis-)appropriated.
Jeff Schnitzer
[EMAIL PROTECTED]
The Maverick MVC Framework: http://mav.sourceforge.net
-Original Message-
From: Scott Taylor [mailto:[EMAIL PROTECTED]]
Sent: Sunday, February 16, 2003 7:43 AM
To: Tag Libraries Users List
Subject: Re: Tag List
Thanks I will look at Maverick. Why is Maverick and Struts considerd
MVC,
when the idea of JSP is part of MVC?
Scott
- Original Message -
From: Schnitzer, Jeff [EMAIL PROTECTED]
To: Tag Libraries Users List [EMAIL PROTECTED]
Sent: Friday, February 14, 2003 8:19 PM
Subject: RE: Tag List
Yes, if you're using JSTL then you will be a whole lot better off with
an MVC framework like Struts or Maverick. I recommend Maverick -
it's
considerably simpler than Struts, yet offers more features. Also,
unlike most other similar frameworks (Struts, WebWork, etc), Maverick
never started out with a now-crufty set of specialized set of JSP tags
-
JSTL works great.
The core distribution includes a sample application that uses JSTL.
http://mav.sourceforge.net
Jeff Schnitzer
[EMAIL PROTECTED]
(yes, I'm the lead developer of Maverick)
- Original Message -
From: Scott Taylor [EMAIL PROTECTED]
To: Tag Libraries Users List [EMAIL PROTECTED]
Sent: Friday, February 14, 2003 10:23 AM
Subject: Re: Tag List
Thanks...how about an entry form?
Also, if I want to do JSP's easier are Struts better?
I will get the book though
Thanks
Scott
- Original Message -
From: Eddie Barna [EMAIL PROTECTED]
To: Tag Libraries Users List [EMAIL PROTECTED]
Sent: Friday, February 14, 2003 6:01 PM
Subject: Re: Tag List
You can pass the value from your search form to the page which
you
have
listed in your email. For example: You have a search form with
a
text
box
titled search
Here's what the page that queries the db would look like now
sql:query var=productQuery dataSource=${productDS}
SELECT * FROM CD WHERE CDTITLE = ?
sql:param value=${param.search}/
/sql:query
You can also expand on this by using the OR statement in your
query.
For
example:
sql:query var=productQuery dataSource=${productDS}
SELECT * FROM CD WHERE CDTITLE = ? OR ARTIST = ?
sql:param value=${param.search}/
sql:param value=${param.search}/
/sql:query
For every condition in your query you must add a sql;param/
tag.
Hope this helps. I really do recomend that you get Shawn
Bayern's
book
titled JSTL in Action. It explains all this in great detail,
plus
everything else.
- Original Message -
From: Scott Taylor [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, February 14, 2003 9:31 AM
Subject: Tag List
I am trying to find a list of tags to help me modify the CD
Shop
Cart
web
application from Sun One.
For example, how do I insert tags that provide a search form
(and
entry
form) rather than simply list everything.
Here is what the code looks like so far:
%@page contentType=text/html%
html
headtitleCD Catalog List/title/head
%@ taglib prefix=c uri=http://java.sun.com/jstl/core; %
%@ taglib prefix=sql uri=http://java.sun.com/jstl/sql; %
body
h1 CD Catalog List /h1
sql:setDataSource var=productDS
url=jdbc:postgresql://localhost:5432/recruitment
driver=org.postgresql.Driver
user=scott password= /
sql:query var=productQuery dataSource=${productDS}
SELECT * FROM CD
/sql:query
TABLE border=1
TR
THID/TH
THCD Title/TH
THArtist/TH
THCountry/TH
THPrice/TH
/TR
c:forEach var=row items=${productQuery.rows}
TR
TDc:out value=${row.ID}//TD
TDc:out value=${row.CDTITLE}//TD
TDc:out value=${row.ARTIST}//TD
Re: EL Functions
JSP 2.0 provides tag-library developers with the ability to expose static methods as functions in their TLDs. These functions will be accessible to authors of any pages that import the containing tag library. This facility also allows JSTL to expose a set of standard functions. The precise set of functions that JSTL 1.1 will expose is still being debated, but it will likely include a limited set of string-manipulation functions and a handful of targeted solutions (such as a 'size' function). Future versions of JSTL can expose more functions as necessary. -- Shawn Bayern JSTL in Action http://www.manning.com/bayern On Sun, 16 Feb 2003, Henri Yandell wrote: From what little I know, JSP 2.0 introduces the concept of functions to EL. I doubt these equate to ECMAScript, but is rather the ability to define your own functions. I'v eno clue if there will be standard-ised functions, though I'd expect JSTL might be the one to determine those. [Sorry, I'm quite clueless but there might be some nuggets there to help you move on, like reading the JSP 2.0 spec] Hen On Sun, 16 Feb 2003, David Goodenough wrote: I notice in the source of Taglibs that there are what appear to be EL functions, but these do not appear in the JSTL reference material. Is there a definition of these functions? Or can we assume that all the functions in JavaScript (EcmaScript) exist in EL? David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem with empty key word on a collection.
On Thu, 13 Feb 2003, Leon Doud wrote: It appears that the empty keyword doesn't always function on a collection. I must be missing something obvious.. The folder object contains a collection of content. The useBean tag isn't initializing the Folder object. Its there so I can use scriptlet debugging code. What exactly does empty check to determine if a collection is empty or not? It looks like that empty is checking if the folder.content is null or not, not if its size is zero. Folder.getContent() returns a type of java.util.Collection. The 'empty' operator is specified to work with java.util.List and java.util.Map (as well as arrays and strings), not java.util.Collection in general. -- Shawn Bayern JSTL in Action http://www.manning.com/bayern - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem with empty key word on a collection.
On Thu, 13 Feb 2003, Leon Doud wrote:
Well that would be fine if it was possible to call the isEmpty()
method on a collection. But since empty is a key word the parser has
a problem with collection.empty.
You could use ${collection[empty]}.
Why not implement the empty keyword on all collections? The method
isEmpty is available in the Collection interface. Was there some sort
of argument against that when the spec was defined?
I believe so; I don't remember the details of the debate, but I think the
justification is that the EL doesn't deal with Collections in general in
any other situation.
--
Shawn Bayern
JSTL in Action http://www.manning.com/bayern
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Standard Taglib 1.0.3: almost ready
On Tue, 11 Feb 2003, Fredrik Westermarck wrote: Will there be a 1.0.3 of the Standard Taglib soon, or are there still issues that needs to be resolved before a release can be made? Our plan is to release Standard Taglib 1.0.3 within a few days -- most likely by 2/17. Shawn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Properties of variables
On Wed, 12 Feb 2003, Eddie Barna wrote: I am working through the JSTL in Action book by Shawn Bayern. Great book by the way. Cool! Great to hear. I have finaly ran into a situation that brought me here. The variable exposed by the sql:query tag has certain properties such as limitedByMaxRows. My question is: How and where can I find a list of all the properties that this variable has. Since we are on the subject of properties, I would appreciate it if anybody knows of a way to get the properties of variables that are exposed by other tags. It's figure 9.3 (page 191) in JSTL in Action. The JSTL specification also describes what properties each exposed variable has. There's no way to determine this in general (short of using Java's reflection facilities, which aren't available directly from JSTL); you need instead to resort to documentation, such as the book or the specification. Hope that helps, -- Shawn Bayern JSTL in Action http://www.manning.com/bayern - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Typecasting the variable inside a c:foreach-loop
On Mon, 10 Feb 2003, Sakke Wiik wrote:
I have a loop where I need to cast the looped objects if
they are of a certain type.
Can someone explain me if it's possible with any standard tags,
or how I could get hold of the storageObject object through some
java-code?
Here's the loop:
c:forEach var=anObject items=${objects}
c:if test=${anObject.typeB}
Need to cast here % TypeB typeB = anObject.typeB %
/c:if
/c:forEach
Java code can refer to the scoped attribute as
pageContext.findAttribute(anObject);
To get typeB, you'd need to cast anObject to the appropriate type and
then call getTypeB().
--
Shawn Bayern
JSTL in Action http://www.manning.com/bayern
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using Standard Tag Library to Display a Request Attribute
On Sun, 9 Feb 2003, Shadow X wrote:
What if I needed to use a key to lookup the parameter value?
For instance:
c:out value=${requestScope['org.apache.struts.Globals.LOCALE_KEY']}
/
org.apache.struts.Globals.LOCALE_KEY actually maps to
org.apache.struts.action.LOCALE
If I'm understanding the request right, the following would work:
${requestScope[requestScope['org.apache.struts.Globals.LOCALE_KEY']]}
--
Shawn Bayern
JSTL in Action http://www.manning.com/bayern
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Using Standard Tag Library to Display a Request Attribute
No, but that's only because 'org.apache.struts.Globals' isn't a scoped
variable; the expression language can't be used to retrieve static fields
in a class. The expression language is designed to access only certain
kinds of data.
--
Shawn Bayern
JSTL in Action http://www.manning.com/bayern
On Sun, 9 Feb 2003, Shadow X wrote:
I tried the nesting of [] but it doesn't seem to work.
Perhaps I should make my situation clearer. I've saved the locale
object under the key org.apache.struts.Globals.LOCALE_KEY (with
setLocale(request,locale) in struts)
Now in my jsp I want to retrieve the locale. I tried:
c:set scope=page var=lo
value=${sessionScope[sessionScope['org.apache.struts.Globals.LOCALE_KEY
']]}/
Language = c:out value=${pageScope.lo.language} /
But all I get is an empty string. The following works, but requires an
extra variable:
%@ page import=org.apache.struts.Globals %
c_rt:set var=locale_key
value=%=org.apache.struts.Globals.LOCALE_KEY%/
c:set scope=page var=locale value=${sessionScope[locale_key]}/
Language= c:out value=${pageScope.locale.language}/
I was wondering if there was a way to do it without using a runtime
expression and an extra variable.
Thanx for your time.
~Shadow
On Sun, 9 Feb 2003, Shadow X wrote:
What if I needed to use a key to lookup the parameter value?
For instance:
c:out
value=${requestScope['org.apache.struts.Globals.LOCALE_KEY']}
/
org.apache.struts.Globals.LOCALE_KEY actually maps to
org.apache.struts.action.LOCALE
If I'm understanding the request right, the following would work:
${requestScope[requestScope['org.apache.struts.Globals.LOCALE_KEY']]}
--
Shawn Bayern
JSTL in Action http://www.manning.com/bayern
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: ELSE for JSTL
On Sat, 8 Feb 2003, Henri Yandell wrote: Why not: c:if test=... c:do foo /c:do c:else bar /c:else /c:if ?? Just to make it a bit nicer in xml look and feel. Which of course is synonymous to choose I think :) Yes, exactly. The c:choose, c:when, and c:otherwise tags simply provide a more generalized syntax since they allow multiple conditions. During the JSR-52 EG's deliberations, most of the members felt that there were definite advantages to a simple c:if tag unencumbered by multi-way conditions; no matter where a c:if tag appears, its body is included if 'test' is true and excluded otherwise. Either way, evaluation continues after the closing /c:if tag. Particularly for large and complex pages, this kind of simplicity -- for, after all, a task that is one of JSTL's simplest functions -- was considered desirable. Note also that XSLT faced an identical problem (or at least a very similar one) and came to the same conclusions. -- Shawn Bayern JSTL in Action http://www.manning.com/bayern - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Counter using Struts Taglibs
On Thu, 6 Feb 2003, Vinay wrote:
Hi All,
How can I define counters using Struts EL tag libraries for
printing purposes in JSP pages
It looks like you're really asking about JSTL tags, not Struts.
You can use c:set to increment a variable, as in
c:set var=counter scope=session value=${counter + 1} /
I am novice and have recently started using these tag libraries.Is
there a link or web site which has tutorials on how to use the tag
libraries.
The JSTL specification is available at http://java.sun.com/products/jstl.
If that's too technical for you at the moment, there are also several
books on JSTL; more info on mine is available at the URL below.
--
Shawn Bayern
JSTL in Action http://www.manning.com/bayern
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using Standard Tag Library to Display a Request Attribute
On Thu, 6 Feb 2003, Renick, Garrel wrote:
c:out value=${requestScope.javax.servlet.error.message} /
Is there a trick to displaying request attributes with JSTL? Is the
expression language interpreting the periods in the attribute name?
Yes, it is. To avoid this, you can use expressions like the following:
c:out value=${requestScope['javax.servlet.error.message']} /
The [] syntax works wherever . works, but it lets you avoid problems when
the property name itself contains a period.
--
Shawn Bayern
JSTL in Action http://www.manning.com/bayern
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: about return in c:if tag
On Thu, 6 Feb 2003, Kishi Mikio wrote: Hi, c:if test=... % return; % /c:if As above, I want to return in c:if tag, but can not In this case, what is the best practice ? Is creating my custom tag (myTag:return) , which return SKIP_PAGE immediately, better ? Thanks in advance You don't seem to mind using scriptlets, so c:if test=... % if (1==1) return; % /c:if would work. Your own my:return would indeed probably be cleaner, though. -- Shawn Bayern JSTL in Action http://www.manning.com/bayern - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jstl type conversion
On Wed, 5 Feb 2003, Steve Morrison wrote:
It seems as if the jstl (1.0.2) coerces all numbers to a Double, where
really what I want is to keep it as an integer.
c:set var=height250/c:set
c:out value=${height/2}/
returns 125.0. I'd like it to return just 125 - any hints?
Not all numbers are coerced to Double, but the result of a division with
/ is, by spec.
If you're concerned simply about display, you can use fmt:formatNumber
to process the number according to your needs.
--
Shawn Bayern
JSTL in Action http://www.manning.com/bayern
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Dynamic HTML Parameters
On Thu, 30 Jan 2003, Chris Yocum wrote:
Hi all,
I have searched the mail archive and I have not found an answer to my
questions. My question is: I have a c:forEach loop that dynamically
generates HTML parameters. Once the user clicks on the submit button, I
programmatically know how many there are since I save the number in a
variable. However, I have no way of combining that number with the param
object. For example, I cannot do c:out value=${param.thing_}${count} /
or c:out value=${param.thing_${count}} /.
I will mock up some code if there is confusion about my question.
Thanks for all the help!
You'll want to build up the string first and then use it as a dynamic
property of 'param':
c:set var=x value=thing_${count} /
c:out value=${param[x]} /
--
Shawn Bayern
JSTL in Action http://www.manning.com/bayern
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to get all request parameters
On Thu, 23 Jan 2003 [EMAIL PROTECTED] wrote:
This is probably a stupid question, but how do I get all the parameters from
the request with their value?
I need some output like:
parameter_1 = output_1
parameter_2 = output_2
I know I can access a certain value with param.key - but a collection
of all keys
... is just ${param}, a Map of all request parameters (with single
values).
--
Shawn Bayern
JSTL in Action http://www.manning.com/bayern
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: c:out Problem
On Tue, 21 Jan 2003, Alejandra De Leon wrote: Hi! Thanks for answering about c:foreach. Now I' m trying to find someone at caucho.com to answer my questions. I have a problem with c:out when I try to display a string with special caracters. When I put algo#134;s as the value of the c:out it displays amp; insted and the browser didn't recognize this. I have to used the code because I'm using netscape. Is there a way to scape special caracters or to avoid this kind of automatically convertion? To avoid the automatic conversion, use the attribute 'escapeXml=false' in the c:out tag. You might want to read through the JSTL standard or pick up a book on JSTL; it'll help with basic features like this. Best, -- Shawn Bayern JSTL in Action http://www.manning.com/bayern -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [JSTL] Is JSTL 1.0 forward compatible w/ JSP 2.0?
On Mon, 20 Jan 2003, Jerome Jacobsen wrote: I was looking at the JSTL code and noticed that the Tags attributes which accept EL are of type String. Then the Tag handler does the EL evaluation. However with JSP 2.0 wouldn't the attribute be the actual Object expected (post evaluation)? In that case is the JSTL 1.0 implementation not JSP 2.0 forward compatible? Perhaps this isn't an issue as the JSP 2.0 container would include a JSTL implementation? In JSTL 1.1 and JSP 2.0, the 'RT' (rtexprvalue) tag libraries will be used, thus allowing the container to process expressions. JSP 2.0 won't use expressions by default in applications that have a deployment descriptor created according to the JSP 1.2 standard's specifications. Thus, existing applications continue to work unmodified. New applications will use the JSTL 1.1 URIs to identify JSTL tag libraries. A JSP 2.0 container need not include a JSTL implementation, but it must include an EL interpreter. Shawn -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: about EL-based JSTL
On Tue, 21 Jan 2003, Kishi Mikio wrote: Mr. Henri and Mr.David, Thank you for your rapid response. From: Henri Yandell [EMAIL PROTECTED] Subject: Re: about EL-based JSTL Date: Sun, 19 Jan 2003 14:09:42 -0500 (EST) I think it's an architectual rather than technical decision. JSP 2.0 will be EL-ised by default [as far as I know] so by using the EL-based JSTL now you might get better forward compatibility. Then again, turning off the EL is just a config option in the web.xml so it won't be very hard. I see. If so, will EL-based tags become de facto standard, and RT-based tags disappear in near future ? That's how it will look, but in terms of the actual implementation, the EL-based tags (i.e., tags that interpret the EL themselves) will go away, and the RT-based tags, which will allow either rtexprvalues or JSP 2.0 EL expressions, will be used. -- Shawn Bayern JSTL in Action http://www.manning.com/bayern -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Standard Taglib 1.0.3: almost ready
We're pleased to announce that we've gone through all bug reports for Standard Taglib 1.0.2, and we're almost ready to produce a new release, 1.0.3. If you have any outstanding issues with the current release -- or if you want to check our fixes to any bugs you've reported -- now would be a great time. Just mail [EMAIL PROTECTED], or post to the regular Bugzilla archive at nagoya.apache.org, if you've got any questions or bugs to report. Thanks for all the feedback, reports, and questions. The implementation benefits immeasurably from your feedback. Shawn Bayern JSTL RI lead -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Can't call the field from a specific table.
On Mon, 13 Jan 2003, John Engilis wrote:
c:forEach items=${Amenities.rows} var=amenitiesRow
c:if test=${amenitiesRow.golf == 'T'}tdliGolf/li/td/c:if
/c:forEach
When I attempt replacing amenitiesRow.golf with amenitiesRow.oa.golf it
does not appear to recognize the data (I don't get any errors).
You really mean ${amenitiesRow[oa.golf]}. You need to use the []
operator when the name of your property contains a dot.
Your other two choices are to give aliases to the column names in your SQL
statement and to refer to rows by index. But using [oa.golf] is
probably the easiest in your situation.
--
Shawn Bayern
JSTL in Action http://www.manning.com/bayern
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: x:set var
On Mon, 13 Jan 2003 [EMAIL PROTECTED] wrote:
All,
For the life of me, I cannot figure out why the following examples produce
different results. Many thanks in advance if anyone can help.
I'm importing an XML doc with the following:
x:parse var=reports
c:import url=reports.xml/
/x:parse
If I use
x:out select=$reports//report[@shortname='biweekly']/id /
I get the expected result, 157.
However, if I use
x:set var=reportID select=$reports//report[@shortname='biweekly']/id
/
c:out value=${reportID} /
I get, [[id: null]].
The xPath syntax is obviously correct, as I'm getting the expected
result with the x:out tag. So, any idea what I'm doing wrong when I
try to expose the same result in the variable reportID?
The x:out tag uses the string-value of the element you have selected.
x:set stores the object representing that node itself, and then c:out
prints the toString() value of that node -- which, per the DOM API, isn't
the same thing as what XPath means by string-value.
To store the value you expect instead of outputting it immediately, you
should use a pattern like
c:set
x:out
/c:set
instead of x:set. Alternatively, you can wrap the XPath expression in
the string() function and continue to use x:set.
Hope that helps,
--
Shawn Bayern
JSTL in Action http://www.manning.com/bayern
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: How to Use a forEach Variable in Scriptlet
On Fri, 10 Jan 2003, Paul Hodgetts, Agile Logic wrote:
If I have a forEach tag:
c:forEach items=${x.y} var=z
How can I access the variable z in a scriptlet?
Something like:
% String a = z.name() %
but that gives a compiler error when it tries to
compile the JSP page. My understanding is that
z gets put in page scope, but I don't know how to
access it from there.
JSTL tags don't expose scripting variables. You'd need either to insert a
jsp:useBean tag or to refer to the scoped attribute, as in
% String a = ((MyClass) pageContext.getAttribute(x)).getName(); %
--
Shawn Bayern
JSTL in Action http://www.manning.com/bayern
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: JSTL confused by overloading accessor methods
On Thu, 9 Jan 2003, Travis McCauley wrote: I've just spent about eight hours trying to figure out a bug in my web-app and it seems to have been caused by overloading a set method. This is by design -- or at least the expected behavior. The JavaBeans introspector ignores overloaded methods when looking for properties. For a JavaBean property 'xxx' to exist (in the default case without BeanInfo classes), three things must be true: - A getXxx() method or setXxx() method must exist. - If they both exist, the return type of getXxx() must match the type of the formal parameter in setXxx(). That is, in TYPE getXxx() and void setXxx(TYPE x) 'TYPE' must be the same. - No more than one setXxx() method may exist. -- Shawn Bayern JSTL in Action http://www.manning.com/bayern -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Need help with x: tags
Hi Tom,
On Thu, 19 Dec 2002, Zvolensky, Thomas J {PGL~Nutley} wrote:
Can someone advise if it is possible using x: tag in JSTL to obtain
the value of an parameter within a tag?
For instance, I have a tag:
version createdate='2002-03-06T21:45:17'
filecreatedate='2002-03-06T21:45:16' filedatasize='25600'
filemodifydate='2002-03-06T21:45:16' filename='Migration Issues.doc'
fileplatform='2' fileressize='0' filetype='doc' id='6359951'
indexed='0' locked='0' mimetype='application/msword'
modifydate='2002-03-06T21:45:17' name='1' nodeid='6359949' number='1'
owner='4763453' providerid='6359950' providername='EXTSHARED'
and would like to retrieve the values for mimetype, filename,
filecreatedate, etc.
Is this possible with JSTL or should I use the XTags library.
Sure, you can use XPath expressions that use the @ shorthand notation
for the attribute axis, so you end up with something like
/version/@mimetype
This means the attribute 'mimetype' of the tag 'version.'
Hope that helps,
--
Shawn Bayern
JSTL in Action http://www.manning.com/bayern
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [JSTL] Help hiding/showing sections on JSP (w/ cookie?)
On Thu, 19 Dec 2002, Wendy Smoak wrote:
x:if select={$showAddress}
tabletrtdstuff/td/tr/table
/x:if
Or can I get at the cookie with JSTL? (And pick out a specific position of
it??) The setting of the cookie is done in a Struts Action, so I've got
Struts (and Struts-EL) tags available if one of those would be easier to
use.
You can indeed read the cookie with expressions like ${cookie.key} in most
cases, but you won't be able to get at a character position easily in the
cookie -- at least not under JSTL 1.0. However, if you delimit the
cookie's value with commas (e.g., Y,N,N,Y,...), you could in principle
loop over the cookie's components with c:forEach and set different
variables depending on what each individual value equals. The rough form
of this solution looks like
c:forEach items=${cookie.foo} var=e varStatus=c
c:if test=${e == 'Y'}
c:set target=${myMap} property=boolean${c.count} value=${true} /
/c:if
/c:forEach
--
Shawn Bayern
JSTL in Action http://www.manning.com/bayern
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: periodic refresh with JSTL c:import
On Wed, 18 Dec 2002, Brian Buckley wrote:
How can one use JSTL to do something in between, such as to update the
c:import once an hour?
c:if test=??? test if applicationScope.x is more than an hour old ???
c:import url=channel.jsp var=x scope=application
c:param name=rssUrl value=http://www.slowurl.rss; /
/c:import
/c:if
c:out value=${applicationScope.x} escapeXml=false /
You could create a Date object and compare the time property of this
object against the current time; Hans has shown how to do this in previous
messages.
It might be easier to use the Cache Taglib, which isn't part of JSTL but
does exactly what you're looking for.
--
Shawn Bayern
JSTL in Action http://www.manning.com/bayern
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Word Separator Character For Bean Key Names...
On Thu, 12 Dec 2002, Hohlen, John wrote:
But this won't work with the EL syntax, right? For example:
${sessionScope.com.abc.fleetsystems.employee}
Won't JSTL the Expression Language (EL) evaluator get confused and look
for nested objects? More specifically:
getCom().getAbc().getFleetsystems().getEmployee()
Hence, I wondering what the standard word separator, or in our case,
package separator character is. I'm guessing that it's an underscore, but
haven't seen any such recommendation.
You must use the [] operator, as in
${sessionScope[com.abc.fleetsystems.employee]}
--
Shawn Bayern
JSTL in Action http://www.manning.com/bayern
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [Howto] use c:import with varReader to import/parse large XMLfile ?
On Mon, 25 Nov 2002, smallufo wrote:
I have a big XML file (about 500Kbytes) ,
while using general
x:parse var=doc
c:import url=/xxx.xml/
/x:parse
x:out select=$doc//xxx/
It costs a lot of time (about 12~14 seconds) to select nodes.
I wonder if varReader can improve the efficiency, I tried but cannot
find how to combine varReader with XML parsing, can somebody give me a
demonstration ?
x:parse accepts a Reader, so you can simply write
c:import url=/xxx.xml var=xml /
x:parse var=doc xml=${xml} /
--
Shawn Bayern
JSTL in Action http://www.manning.com/bayern
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: is it possible to re-use an existing sql:query variable?
On Mon, 25 Nov 2002, Mark Goking wrote:
is it possible to re-use an existing sql:query variable?
Yes.
c:forEach var=t items=${test.rows}
c:out value=${t.test}/
/c:forEach
now.. i want to use it in another forEach
c:forEach var=t items=${test.rows}
c:out value=${t.test}/
/c:forEach
is this possible? or do i have to do something else first
Yes, it's possible just as you've written it.
--
Shawn Bayern
JSTL in Action http://www.manning.com/bayern
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [standard] nested forEach tags?
On Sat, 23 Nov 2002, Wendy Smoak wrote:
Can you nest c:forEach tags? I can't find an example of it, and
it's not working for me.
Sure.
c:forEach items=${itemList} var=item
hr
c:out value=${item.id}/. c:out value=${item.text}/br
c:forEach items=${item.options} var=option /
c:out value=${option.text}/
/c:forEach
c:out value=${item.answer}/br
/c:forEach
The first /c:forEach tag ends the loop.
Should this be working? Does anyone see anything wrong with this?
It looks right to me. Are you sure you're using our Standard Taglib
implementation? This could be a bug with other partial implementations.
Shawn
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: JSTL Bug - requestScope[var] not working
On Thu, 21 Nov 2002, Scott Goldstein wrote:
I think this may have already been posted, but I don't recall the
answer.
Aren't the following two snippets identical?
%
String value = foo;
%
c:out value=${requestScope[value]}/
and
%= request.getAttribute(value) %
Nope. Scripting variables are not automatically made into scoped
attributes, and the EL can only refer to scoped attributes. If you added
pageContext.setAttribute(foo, foo);
to the upper scriptlet, then the code would be identical.
The first is returning null and the second is returning the
appropriate attribute value. I looked in the JSTL spec and it looks
like the first should work.
Is this a bug?
No, the behavior is as expected.
--
Shawn Bayern
JSTL in Action http://www.manning.com/bayern
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Question for Bergsten
On Thu, 21 Nov 2002, Henri Yandell wrote: I wonder if Sun will ever get around to dumping the acronym-rule bit from their coding standard. Or is it already gone? [as in, URL is wrong by the Java Coding Standard, but Url is right] No, it's still there, but it's not universally followed. To my knowledge, it's also unclear what you're supposed to do with two adjacent acronyms, as in HttpURLConnection, which mixes the two approaches. Shawn -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: JSTL Bug - requestScope[var] not working
On Thu, 21 Nov 2002, Scott Goldstein wrote:
I'm not sure that I follow. How about these two snippets:
%
String value = foo;
%
c:out value=${requestScope[value]}/
and
c:out value=${requestScope[foo]}/
The second one works, while the first doesn't.
Yes. Again, this is correct. In fact, the problem is the same: in the
first example (which is the same as what you showed before), 'value' is
simply a scripting variable. It is not automatically visible to the EL;
the EL has no way to read scripting variables. Instead, it must be made a
scoped variable explicitly, as by pageContext.setAttribute().
The only difference is that the second is using a string literal for
the index and the first is using a scripting variable. Are you saying
that scripting variables cannot be used as indexes?
I'm saying that scripting variables cannot be accessed at all by the EL.
Any EL-accessible values can be used as indices.
Shawn
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: RV: Manage Results obtained from ResultSets
On Mon, 18 Nov 2002, SANZ SANFRUCTUOSO, Manuel wrote: OK, but... How can I manage this Result object r with JSTL core tags? You first need to expose it as a scoped variable. Instead of -- % Result r = ResultSupport.toResult(rs; % -- simply write % pageContext.setAttribute(r, ResultSupport.toResult(rs)); % -- Shawn Bayern JSTL in Action http://www.manning.com/bayern -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: How to maintain collections with JSTL?
On Fri, 15 Nov 2002, Zaretzke, Peter wrote:
public void setList( String value ) {
list.add ( value );
}
does not work because it does not meet the parameter expectations (
List vs. String ) for beans. I know that I can write more setZZZ()
methods to add something to the List but it breaks somehow the naming
conventions for beans (getXxx, setXxx). And how to add a new entry to
the map?
Unless you're happy with writing a new setXxx() method that modifies a
collection (which is a clever idea but still something of a hack because
it violates the intent of the JavaBeans specification), it's actually
quite hard to manage collections in this way with JSTL. Since JSTL is
focused on presentation -- on reading data structures rather than writing
them -- it's likely going to be easier to modify collections in a back-end
servlet (or with a new custom tag you write -- one that's specific to your
own custom data).
Shawn
--
To unsubscribe, e-mail: mailto:taglibs-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:taglibs-user-help;jakarta.apache.org
RE: namespaces in x:parse
On Thu, 14 Nov 2002 [EMAIL PROTECTED] wrote: x:registerNamespace prefix=xsl uri =http://www.w3.org/1999/XSL/Transform; scope=.../ !-- registerNamespace tag is NOT defined in the JSTL1.0 specification !!! -- following name might look more familiar to anybody; no explanation needed. x:xmlns prefix=... uri=... scope=.../ Names that begin with xml are reserved by the XML specification. -- Shawn Bayern JSTL in Action http://www.manning.com/bayern -- To unsubscribe, e-mail: mailto:taglibs-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:taglibs-user-help;jakarta.apache.org
Re: skip x:parse, apply x:out straight to a pre-build DOM instance
On Thu, 14 Nov 2002 [EMAIL PROTECTED] wrote:
I also tried such coding :
c:set var=MyDOM value=${prebuild_DOM}/
x:out select=${MyDOM}//*/
then I was welcomed by a NullPointerException.
You can do it, but the syntax you're using is wrong. The JSTL tags don't
care whether the DOM you're using has come from x:parse or from a
servlet. But either way, you must refer to it using XPath variables, not
the JSTL EL inside the 'select' attribute. Thus, you'd write
x:out select=$MyDOM//* /
--
Shawn Bayern
JSTL in Action http://www.manning.com/bayern
--
To unsubscribe, e-mail: mailto:taglibs-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:taglibs-user-help;jakarta.apache.org
Re: RV: Manage Results obtained from ResultSets
On Thu, 14 Nov 2002, SANZ SANFRUCTUOSO, Manuel wrote: Has anybody used the ResultSupport class? I'd like to call a JavaBean to give me back a JSTL Result objet to be able to process it as if I would have had it from a sql:query action. I don`t know how to get this object in my JSP and manage it. There are some articles that say something about it, but none of them give examples. Can anybody help me? The ResultSupport class should do what you want, assuming that you're starting with a JDBC ResultSet object. Usage works just like this: Result r = ResultSupport.toResult(resultSet); -- Shawn Bayern JSTL in Action http://www.manning.com/bayern -- To unsubscribe, e-mail: mailto:taglibs-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:taglibs-user-help;jakarta.apache.org
Re: WARs missing from JSTL 1.0.2?
On Thu, 14 Nov 2002 [EMAIL PROTECTED] wrote: Am I just being stupid or are the WAR files missing from the binary distribution of JSTL 1.0.2? Indeed, I think the latest distribution doesn't have the sample and 'doc' WARs. The problem was on my end; I've been meaning to correct it but haven't had a chance yet. Thanks for the reminder. Shawn -- To unsubscribe, e-mail: mailto:taglibs-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:taglibs-user-help;jakarta.apache.org
Re: Don´t exists the c:declare ... tag
On Mon, 11 Nov 2002, Rodolfo Martin wrote: I don´t know what happens but when I try a c:declare ... tag the compiler tells me that the tag doesn´t exists. However the other core tags work fine. I'm working with Tomcat 4.1 and the JSTL 1.0 release from June 21: jakarta-taglibs-standard-1.0.tar.gz Please tell me what I'm doing wrong. I appreciate some full example code that works fine. There is no c:declare tag in JSTL. It was present in very old early-access releases, but it was removed long before final release of JSTL 1.0. If you have in mind the version of c:declare that creates a scripting variable, you can use jsp:useBean instead. (Don't be fooled by the name bean; you can use it to create a scripting variable of any type.) -- Shawn Bayern JSTL in Action http://www.manning.com/bayern -- To unsubscribe, e-mail: mailto:taglibs-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:taglibs-user-help;jakarta.apache.org
Re: DTD for the various standard taglibs?
On Mon, 11 Nov 2002, Manfred Riem wrote: Does anyone have DTD modules for the standard taglibs? I need to have those to do document validation offline ;) DTDs won't help you; JSP tags use namespaces, which are beyond the capabilities of DTDs. Shawn -- To unsubscribe, e-mail: mailto:taglibs-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:taglibs-user-help;jakarta.apache.org
Re: Alternatives to this hack ?
On Sat, 9 Nov 2002, Paul Campbell wrote: First, I just used the JSTL taglibs-mailer for the first time. It was remarkable how easy and effective it was. Just a quick correction. The Mailer Taglib is not part of JSTL. It's an offering from Jakarta Taglibs, which is not identical with JSTL. does not provide a technique to execute a method such at % ef.doToString(); % which I could use in the EL based mailer or assign to a variable. Is there a better way of executing a method that returns a sting into an EL variable? The Mailer Taglib doesn't support the JSTL EL, and the EL in JSTL 1.0 won't let you access that method unless you provide a wrapper class. In JSP 2.0, you'll be able to associate that method with a function. -- Shawn Bayern JSTL in Action http://www.manning.com/bayern -- To unsubscribe, e-mail: mailto:taglibs-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:taglibs-user-help;jakarta.apache.org
Re: JSTL snippet
On Fri, 8 Nov 2002, Henri Yandell wrote: Apologies if this is in one of the books on JSTL, I've only got Shawn's and it's not in there afaik. Heh - the snippet is actually almost identical to Listing 9.1 in JSTL in Action. :-) (It actually uses a slightly different approach, but the functionality is the same.) Shawn -- To unsubscribe, e-mail: mailto:taglibs-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:taglibs-user-help;jakarta.apache.org
Re: fmt:setLocale problem again
I believe the problem is just that you're not using the well-known URI for the FMT library: http://java.sun.com/jstl/fmt. This causes our validator not to recognize that your library is actually part of JSTL. (I'm not sure whether to consider this a bug or not; since the well-known URIs are always appropriate, it's not clear what's supposed to happen when you introduce a custom one. Any comments?) -- Shawn Bayern JSTL in Action http://www.manning.com/bayern On Wed, 6 Nov 2002, Alberto Tomas wrote: Hy all, I posted this question 3 weeks ago and nobody has answered it. I post again it stilling to find a solution to my problem. Thanks. I'm using the i18n tags of JSTL(1.0.2) in my JSP which is running over jboss-3.0.1RC1_tomcat-4.0.4. My JSP has these i18n tags: % taglib uri=jstl-fmt prefix=fmt % fmt:setLocale value=en scope=session/ I have added standard.jar and jstl.jar to WEB-INF/lib, fmt.tld to WEB-INF and the following tags to web.xml: taglib taglib-urijstl-fmt/taglib-uri taglib-locationfmt.tld/taglib-location /taglib When the JSP is called, the following exception appears: org.apache.jasper.JasperException: Illegal scope attribute without var in fmt:setLocale tag. Somebody knows what's wrong? Thank you in advance. _ MSN Fotos: la forma más fácil de compartir e imprimir fotos. http://photos.msn.es/support/worldwide.aspx -- To unsubscribe, e-mail: mailto:taglibs-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:taglibs-user-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:taglibs-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:taglibs-user-help;jakarta.apache.org
Re: jrun jstl
On Wed, 30 Oct 2002, Lorenzo Sicilia wrote:
The Sql tag is very usefull but I read in JSTL in ACTION that it don't
support pooling connection. Is true?
The sql:setDataSource tag, when used to create a DataSource, doesn't
support pooling (unless you somehow have a pooling JDBC driver, which
isn't the way things are supposed to work). However, the SQL tags can
support pooling by using, rather than creating, a DataSource.
2-
I need read a recorset JSTL with JSP script because the JSTL tag put
\n each time I close a tag. I need an output without \n but I like
JSTL recorset.
c:set var=language_set value=it /2
sql:query var=elenco
SELECTID_news,data,
titolo_c:out value=${language_set} / as titolo,
abstract_c:out value=${language_set} / as abstract,
testo_c:out value=${language_set} / as testo,
data
FROM tb_news
/sql:query
!--
The follow script don't work. Do you now where path recorset variables are?
--
%
out.print(elenco);
%
Note first that it's better to be using sql:param and the '?'
placeholder syntax for SQL, rather than using c:out inside
sql:query. But that doesn't address your problem.
I'm actually not sure what problem you *are* having: c:out shouldn't
print newlines at the end of its output. However, when you follow c:out
with a newline (outside the tag), then *that* newline is printed. But
you'd have the same problem with scriptlets.
Anyway, to answer your specific question, you'd write
%= pageContext.findAttribute(elenco) %
This is better than out.print(), and it retrieves the scoped attribute via
the PageContext object, which is necessary, for it's not a scripting
variable (just a scoped attribute).
--
Shawn Bayern
JSTL in Action http://www.jstlbook.com
--
To unsubscribe, e-mail: mailto:taglibs-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:taglibs-user-help;jakarta.apache.org
Re: multiple /x:if
I hate to pass the blame, but this looks, if anything, like a
JSP-container bug. What JSP container are you using?
--
Shawn Bayern
JSTL in Action http://www.jstlbook.com
On Wed, 30 Oct 2002, Þorgils Völundarson wrote:
hi,
I just noticed that the jstl x tag writes out /x:if tags when iterating
through the xml file and the number of /x:if is the same as the number of
iterations the loop needs to find the real result. This of course does not
comply with well-formedness Below is the code that generates the page and
after that what it serves. Any ideas?
table class=main
tr
td class=main1
x:forEach select=$data//page
x:if select=@pageid = $param:pageID
div class=main_data_headx:out select=pageHeadIS//divhr
class=style /
x:if select=pageContent/jspfile!=''
c:set var=jspfile
x:out select='pageContent/jspfile'/
/c:set
c:import url=${jspfile}/
/x:if
x:if select=pageContent/contentIS!=''
x:out select='pageContent/contentIS'/
/x:if
/x:if
serves out this:
table class=main
tr
td class=main1
/x:if
/x:if
/x:if
/x:if
/x:if
/x:if
/x:if
div class=main_data_headÚtgefið efni tengt krabbameinsskrá/divhr
class=style /
...
Kveðja,
Þorgils Völundarson
Krabbameinsfélag Íslands, Krabbameinsskrá
Beinn sími: 540 1973
netfang: [EMAIL PROTECTED]
gsm: 698 5302
--
To unsubscribe, e-mail: mailto:taglibs-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:taglibs-user-help;jakarta.apache.org
--
To unsubscribe, e-mail: mailto:taglibs-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:taglibs-user-help;jakarta.apache.org
Re: multiple /x:if
Hmm - I haven't heard of any problems reported like this. Could you send
a whole page, along with all of the data that it uses (e.g., XML files) --
of course, only if that's easy to do.
Shawn
On Wed, 30 Oct 2002, Þorgils Völundarson wrote:
I´m using tomcat 4.0.4
At 08:16 30.10.2002 -0500, you wrote:
I hate to pass the blame, but this looks, if anything, like a
JSP-container bug. What JSP container are you using?
--
Shawn Bayern
JSTL in Action http://www.jstlbook.com
On Wed, 30 Oct 2002, Þorgils Völundarson wrote:
hi,
I just noticed that the jstl x tag writes out /x:if tags when iterating
through the xml file and the number of /x:if is the same as the
number of
iterations the loop needs to find the real result. This of course does not
comply with well-formedness Below is the code that generates the page and
after that what it serves. Any ideas?
table class=main
tr
td class=main1
x:forEach select=$data//page
x:if select=@pageid = $param:pageID
div class=main_data_headx:out select=pageHeadIS//divhr
class=style /
x:if select=pageContent/jspfile!=''
c:set var=jspfile
x:out select='pageContent/jspfile'/
/c:set
c:import url=${jspfile}/
/x:if
x:if select=pageContent/contentIS!=''
x:out select='pageContent/contentIS'/
/x:if
/x:if
serves out this:
table class=main
tr
td class=main1
/x:if
/x:if
/x:if
/x:if
/x:if
/x:if
/x:if
div class=main_data_headÚtgefið efni tengt krabbameinsskrá/divhr
class=style /
...
Kveðja,
Þorgils Völundarson
Krabbameinsfélag Íslands, Krabbameinsskrá
Beinn sími: 540 1973
netfang: [EMAIL PROTECTED]
gsm: 698 5302
--
To unsubscribe,
e-mail: mailto:taglibs-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail:
mailto:taglibs-user-help;jakarta.apache.org
--
To unsubscribe, e-mail: mailto:taglibs-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail:
mailto:taglibs-user-help;jakarta.apache.org
Kveðja,
Þorgils Völundarson
Krabbameinsfélag Íslands, Krabbameinsskrá
Beinn sími: 540 1973
netfang: [EMAIL PROTECTED]
gsm: 698 5302
--
To unsubscribe, e-mail: mailto:taglibs-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:taglibs-user-help;jakarta.apache.org
--
To unsubscribe, e-mail: mailto:taglibs-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:taglibs-user-help;jakarta.apache.org
Re: jrun jstl
On Wed, 30 Oct 2002, Lorenzo Sicilia wrote:
I am a newbie you have some link that explain how to create a
Datasource with pooling? with JSP is possible or I must use Servlet?
It's a fairly general topic. Typically, to instantiate a DataSource, you
just use a class that a database vendor provides -- or alternatively a
pooling DataSource that can be layered on top of any driver, as in the
DBCP package from Jakarta Commons at
http://jakarta.apache.org/commons/dbcp.html
Note first that it's better to be using sql:param and the '?'
placeholder syntax for SQL, rather than using c:out inside
sql:query. But that doesn't address your problem.
I now but why is better your solution? Memory usage?
Security. Using '?' and c:param ensures that any dangerous characters
will be escaped. By dangerous, I mean characters like a single quote
(') that could alter the sense of your SQL statement and end up hijacking
it to produce unintended results.
--
Shawn Bayern
JSTL in Action http://www.jstlbook.com
--
To unsubscribe, e-mail: mailto:taglibs-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:taglibs-user-help;jakarta.apache.org
Re: jrun jstl
On Wed, 30 Oct 2002, Lorenzo Sicilia wrote:
I use JRUN4 and Mysql.
I have com.mysql.jdbc.Driver OpenSource and org.gjt.mm.mysql.Driver by
Macromedia.
Are there Class database vendor provides?
Yes, both of those classes are implementations of the JDBC Driver
interface that come ultimately from the database vendor. I don't use
MySQL, so I don't know offhand if they produce their own pooling
DataSource. You can, however, use Jakarta Commons's DBCP.
Security. Using '?' and c:param ensures that any dangerous characters
will be escaped. By dangerous, I mean characters like a single quote
(') that could alter the sense of your SQL statement and end up hijacking
it to produce unintended results.
Ok, but I think the true problem is about INSERT or DELETE. Select is
not very dangerous. or no?
Hijacked SELECT statements can be dangerous if you're concerned about who
gains read-only access to your data.
--
Shawn Bayern
JSTL in Action http://www.jstlbook.com
--
To unsubscribe, e-mail: mailto:taglibs-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:taglibs-user-help;jakarta.apache.org
Re: Still Not Getting switching between EL Expression and JSPscripting
On Wed, 30 Oct 2002, aps olute wrote:
1. First thing is, using jsp:useBean the way I did, puts as Pets
bean in session scope right? And this is in the JSP script domain not
JSTL ?
When jsp:useBean creates a scripting variable, the variable is always
backed by a scoped attribute. In this case, the variable is a local
scripting variable and a session-scoped variable.
2. How then do I get to that session variable Pets via JSTL? is the
${sessionScope.Pets} in the c:forEach tag not correct? If not please
show me the proper way.
You're doing it correctly; ${sessionScope.Pets} is fine...
3. and once its in the JSTL, how to iterate this correctly?
... however, you'd can't use c:forEach to iterate over a RowSet. You
can convert a ResultSet to a JSTL Result -- which is iterable via
c:forEach -- by using the JSTL API classes in support of such
operations.
4. Is session the wrong scope? Meaning if the database contents has
changed, the RowSet will not get updated since a Pets bean currently
exist in session and will got retrieve new data until the session
expires? Any elaboration on this is appreciated.
This is a broader question that's hard to answer based on just what you've
shown. If jsp:useBean finds a variable already existing under the name
and scope that you've provided, it will use that variable instead of
installing a new instance of the class you've provided. Whether the
variable needs to be synchronized or not, and how you should manage its
lifecycle, are questions dependent on your application's overall design.
--
Shawn Bayern
JSTL in Action http://www.jstlbook.com
--
To unsubscribe, e-mail: mailto:taglibs-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:taglibs-user-help;jakarta.apache.org
RE: multiple /x:if
On Wed, 30 Oct 2002, Gideon, Thomas wrote: It looks to me like you have a syntactic error, one too many closing /c:if tags. Which version of JSTL are you using? 1.02, at least for the core library, is better about catching an un-matched end tag during translation. Perhaps there is a bug in the xml taglib, but you can easily work around it be correcting your JSP. Catching mismatched tags is not the function of JSTL; it's done automatically by the container, and version 1.0.2 shouldn't be any different in this regard from 1.0.1. Please let me know if you've indeed noticed otherwise. Any mismatched tags should be caught correctly by the container for the Standard Taglib 1.0.1. But indeed, you are correct that dangling end tags will simply be printed out by a JSP container. This behavior is appropriate per the JSP specification; under the non-XML syntax, an unmatched /x:if tag is simply template text. -- Shawn Bayern JSTL in Action http://www.jstlbook.com -- To unsubscribe, e-mail: mailto:taglibs-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:taglibs-user-help;jakarta.apache.org
Re: Still Not Getting switching between EL Expression and JSPscripting
On Wed, 30 Oct 2002, aps olute wrote: May I bother you with specifically which JSTL class API I should use? Sure - it's no bother. Is it javax.servlet.jsp.jstl.sql? Yes - that's the package, and ResultSupport is the class. But then am back to scripting or java coding and not really using JSTL tags? Right - but JSTL tags aren't meant, in most cases, to be the *only* code in an application. They're just meant to be the presentation code. In this case, you'd just be setting up some data (e.g., in a listener, filter, or servlet) for the purposes of presentation. Any equivalent tags I can use? It's possible that something could be added in a future version of JSTL, but JSTL doesn't have any support for ResultSet at this point. One possibility is to add a function that converts a ResultSet to a Result object (and perhaps also closes the ResultSet). Btw, I was looking at your book yesterday and can not find a sample on it. The closest one is using sql:query tags and then use c:forEach, but I already have Bean like CachedRowset, am still lost. Right - I don't cover it because it's not in JSTL. :) See, however, chapter 14 and appendix B for examples of ResultSupport. -- Shawn Bayern JSTL in Action http://www.jstlbook.com -- To unsubscribe, e-mail: mailto:taglibs-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:taglibs-user-help;jakarta.apache.org
Re: jrun jstl
On Wed, 30 Oct 2002, Lorenzo Sicilia wrote: sorry but I am very newbie :o) my script: % ResultSet pippo = (ResultSet) pageContext.findAttribute(elenco); out.print(pippo.getRows()); % it don't work. The problem is the cast. the error is: 411. ResultSet pippo = (ResultSet) pageContext.findAttribute(elenco); ^---^ *** Error: Type ResultSet was not found. First, you either need to qualify the class's name with a package or % page import=... % the right package. Second, you don't really mean ResultSet in this case; you're referring to a JSTL Result. Thus, if you *must* use a scriptlet -- and I still fail to see what it's doing for you that the JSTL tags aren't -- then you can write % page import=javax.servlet.jsp.jstl.sql.Result % ... % Result pippo = (Result) ...; ... % I strongly recommend not doing this, though, and using the JSTL tags instead. The issue you noted with line breaks will affect you with scriptlets as much as it will with JSTL tags. -- Shawn Bayern JSTL in Action http://www.jstlbook.com -- To unsubscribe, e-mail: mailto:taglibs-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:taglibs-user-help;jakarta.apache.org
RE: JSTL BUG? Url problem
On Tue, 29 Oct 2002, flare wrote: I was able to use dynabeans in out and fmt tags but not in param, that's strange I know .. since I should to use the code in production I hope next releases of JSTL won't break the compatibility with the clean but (now I guess) unsupported format I'm using ! It would be very sad switching to scriptlets :( Again, it'd be helpful if you posted a complete page that demonstrates the difference. The code that the Standard Taglib uses to interpret the expression is the same for both tags. Thus, I don't simply mean that the behavior you're noting is nonstandard; I'm suggesting it's not happening the way you're describing if you're using our implementation. -- Shawn Bayern JSTL in Action http://www.jstlbook.com -- To unsubscribe, e-mail: mailto:taglibs-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:taglibs-user-help;jakarta.apache.org
RE: JSTL BUG? Url problem
On Tue, 29 Oct 2002, flare wrote: I'm using latest stable Apache JSTL Implementation on Resin 2.1.5 Are you sure you're not using Resin's JSTL implementation? See http://www.caucho.com/news/2002-06-12.xtp for more information. -- Shawn Bayern JSTL in Action http://www.jstlbook.com -- To unsubscribe, e-mail: mailto:taglibs-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:taglibs-user-help;jakarta.apache.org
Re: sql jstl taglib - accessing to resultset metadata?
On Mon, 28 Oct 2002, Donald Ball wrote: When using the sql jstl taglib, is there any way to access the resultset metadata? I'm looking for a qnd way to get at the column sql types. EA versions of JSTL supported this, but version 1.0 of the specification did not, primarily because it wasn't clear that JSTL should be used for such advanced applications and because there were some tricky implementation issues (concerning, e.g., what should be done with exceptions that ResultSetMetaData methods throw). If you need access to metadata, it's probably best to write your database-access code in a servlet. If you think it would be particularly convenient for a future version of JSTL to offer this feature, you could send a comment to the official JSTL feedback address at [EMAIL PROTECTED] -- Shawn Bayern JSTL in Action http://www.jstlbook.com -- To unsubscribe, e-mail: mailto:taglibs-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:taglibs-user-help;jakarta.apache.org
Re: sql jstl taglib - accessing to resultset metadata?
On Mon, 28 Oct 2002, Henri Yandell wrote: Out of interest, I wonder if most of the people who hit this problem only want access to the name of the column? And then a smaller group simply want the type? [not that I recall if jstl offers this or not]. JSTL offers the name but not the type. (At least, not the type in JDBC terms; you can always get the Java object type with '.class'.) Is it possible to offer a subset of the info in the metadata without crashing into all the pain? Sure. Offering name in JSTL 1.0 seemed like a suitable inflection point; it's possible that more could be offered in the future if it's not problematic and if there's a compelling reason to. -- Shawn Bayern JSTL in Action http://www.jstlbook.com -- To unsubscribe, e-mail: mailto:taglibs-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:taglibs-user-help;jakarta.apache.org
Re: JSTL BUG? Url problem
On Mon, 28 Oct 2002, flare wrote:
c:forEach var=item items=${requestScope.asteAllegati} varStatus=status
c:url value=/showAllegati.do var=show
c:param name=id value=${requestScope.id}/
c:param name=tipo value=${requestScope.tipo} /
c:param name=key value=${item.a_nomefile} /
/c:url
...
I've tried but doesn't work.. if I try to render the url with a
dynabean accessor (a_nomefile or others) I get an error, the out tag
works fine instead. I'm using JSTL on Resin 2.1.5 + Linux
I'm not really familiar with DynaBeans and how they work. My point is
just that if
c:out value=${item.a_nomefile} /
works, then a c:param tag that uses the same expression ought to work as
well. Your previous message indicated that there was some difference
between the two in the same JSP page, and I wanted to confirm that that
was what you meant.
--
Shawn Bayern
JSTL in Action http://www.jstlbook.com
--
To unsubscribe, e-mail: mailto:taglibs-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:taglibs-user-help;jakarta.apache.org
Re: JSTL BUG? Url problem
On Sun, 27 Oct 2002, flare wrote:
c:param name=key value=${item.a_nomefile} /
[...]
a href='showAllegati.do?id=c:out value=${requestScope.id}/tipo=c:out
value=${requestScope.tipo}/key=c:out value=${item.a_nomefile} /'
is that a bug or simply dynabens cannot be used that way?
Irrespective of whether you're using DynaBeans or not, if it works in the
latter case, it should work in the former one. That is, the two
expressions you've shown are identical, and both tags evaluate their
attributes as String objects.
--
Shawn Bayern
JSTL in Action http://www.jstlbook.com
--
To unsubscribe, e-mail: mailto:taglibs-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:taglibs-user-help;jakarta.apache.org
Re: Encoding URL
On Fri, 25 Oct 2002, Stefan wrote:
Hi,
How can I rewrite the URL (encode) for session tracking within this forEach tag:
c:forEach var=boundaryStart begin=0 end=${r.rowCount -1} step=${perPage}
a href=?name=%= name %location=%= location %sex=%= sex
%isPostBack=yesbegin=c:out value='${boundaryStart}'/
[c:out value=${boundaryStart}/ - c:out value=${boundaryStart +
perPage -1}/]/anbsp; /c:forEach
Simply use the c:url and c:param tags.
--
Shawn Bayern
JSTL in Action http://www.jstlbook.com
--
To unsubscribe, e-mail: mailto:taglibs-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:taglibs-user-help;jakarta.apache.org
Re: EL: Inconsistent bean introspection behaviour
Hi Kenny. Responses below --
On Thu, 24 Oct 2002, MacLeod, Kenny wrote:
I've just started delving into JSTL, and I've run into some
inconsistent behaviour between some of the tags. This behaviour
concerns how the EL evaluates bean expressions.
For example, say I have a bean user, with a method getUserName().
The EL expression ${user.userName} works fine in all cases.
However, if I use the expression ${user.UserName} (note the change
of case), then it works in some cases, but not others.
Per the JavaBeans specification, ${user.userName} should work, and
${user.UserName} should not work.
Specifically, it works for the value attributes of c:set and
c:out, but it doesn't work for fmt:formatDate or c:param. The
latter cases throw the exception 'Unable to find a value for
UserName in object'.
I've tried 1.0.1 and 1.0.2, but both behave the same. I can't find
any previous mention of this problem, either. A read through the spec
doesn't yield any clues, but I could be missing something.
Are you certain that you've factored out all other possibilities. In the
minimal case, it works correctly for me. That is, for me, given the
following start to a page:
% taglib prefix=c uri=http://java.sun.com/jstl/core; %
% taglib prefix=fmt uri=http://java.sun.com/jstl/fmt; %
%!
public static class Foo {
public String getUserName() { return George; }
}
%
% pageContext.setAttribute(user, new Foo()); %
the following prints George:
c:out value=${user.userName} /
and the following yields an error:
c:out value=${user.userName} /
I'm using 1.0.2, but nothing in 1.0.2 should differ from 1.0.1 or 1.0 in
this regard.
Please post more information if you can reproduce the bug. Thanks,
--
Shawn Bayern
JSTL in Action http://www.jstlbook.com
--
To unsubscribe, e-mail: mailto:taglibs-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:taglibs-user-help;jakarta.apache.org
Re: how to close sql:query resultset
On Wed, 23 Oct 2002, Mark Goking wrote: once you use sql:query var=test and then c:forEach is there a way to close that var 'test' ? or we just leave it? i think this is a waste of resource 'test' doesn't represent a ResultSet; it represents a temporary cache of your data, and it will be garbage collected as necessary. The goal was to prevent the exposure of hard resources (like database connections) to JSP page authors -- and thus let page authors avoid having to worry about resource deallocation. -- Shawn Bayern JSTL in Action http://www.jstlbook.com -- To unsubscribe, e-mail: mailto:taglibs-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:taglibs-user-help;jakarta.apache.org
Re: Special Chars in Param Name
On Mon, 21 Oct 2002, Chen, Gin wrote:
Hi all,
How can I use jstl when accessing values with special chars in
the name? In particular, the period. I have a param that is being
passed in as user.name for example. It does not mean name in user
object, it just comes from someone declaring fields as:
input type=text name=user.name
input type=text name=user.email
etc..
how about when the special value name is in one of the scopes?
I cant do pageScope.user.name i'm assuming.
Right, but you can use the '[]' notation, as in
${pageScope[user.name]}
If they come directly from a form, then you'll want
${param[user.name]}
--
Shawn Bayern
JSTL in Action http://www.jstlbook.com
--
To unsubscribe, e-mail: mailto:taglibs-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:taglibs-user-help;jakarta.apache.org
Re: might have found a bug in jslt 1.0.2
On Thu, 17 Oct 2002, peter lin wrote:
we did verify acookie exists. I should have been more clear in my
original email.
That's not really the issue; the question is what's causing the error
logs that you're suggesting are indicative of a bug. Since the Standard
Taglib simply results 'acookie.value' into a call to getValue() of your
Cookie, it seems unlikely that the problem lies with the Standard Taglib,
unless I'm misunderstanding your report.
shouldn't JSTL throw an exception, since acookie is wrapped, so
using c:out value=${acookie.value.name}/ is the correct syntax.
Using c:out value=${acookie.name}/ should throw an exception,
rather than go into an infinite loop and generate megs of error logs?
No, the tag should simply result in a call to
acookie.getName().toString(). That's why I'm suggesting you throw
correspondent code in a scriptlet and see if it fails in the same way.
--
Shawn Bayern
JSTL in Action http://www.jstlbook.com
--
To unsubscribe, e-mail: mailto:taglibs-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:taglibs-user-help;jakarta.apache.org
Re: might have found a bug in jslt 1.0.2
On Thu, 17 Oct 2002, peter lin wrote:
It looks like using c:out value=${acookie.name}/ won't retrieve
the value, since acookie is a hashentry, it can't do
acookie.getName().toString(). I'm guessing that is correct
functionality right?
Right, for ${cookie} is a Map of all cookie names to Cookie instances.
So, in the context of the test page, where does the bug come up?
--
Shawn Bayern
JSTL in Action http://www.jstlbook.com
--
To unsubscribe, e-mail: mailto:taglibs-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:taglibs-user-help;jakarta.apache.org
Re: print out the items of a collection in reverse order
On Fri, 18 Oct 2002, Hao Ding wrote:
Is there a way to print out the items of a collection (e.x an array)
in reverse order using c:forEach or some other JSTL core tags?
Not as such. But since you ask, one solution does occur to me:
You can loop through the collection with c:forEach the first time and
add elements to a SortedMap with a key derived from the negation of the
current 'count', then loop through this new SortedMap. (To do this
properly, you'd need first to determine the collection's size. Then,
you'd need to produce each new key with fmt:formatNumber based in part
on this size, for keys set by c:set target=... property=... are
always textual, and numerical keys won't, by default, sort lexically the
way you want them to. To put it another way, you need to pad the numbers
with zeroes by using 'minIntegerDigits'.)
Thus, one solution that prints out the elements of an array or List named
'original' in reverse order could look like this:
jsp:useBean id=reversed class=java.util.TreeMap /
c:forEach items=${original} var=item varStatus=s
c:set var=size value=${s.count} /
/c:forEach
c:forEach items=${foo} var=item varStatus=s
fmt:formatNumber value=${size-s.count}
minIntegerDigits=${size/10 + 1} var=n /
c:set target=${reversed} property=${n} value=${item} /
/c:forEach
c:forEach items=${reversed} var=item
c:out value=${item.value} /
/c:forEach
However, I think we're long past the point where it's easier to do this in
a servlet or some other backing Java code. :-)
--
Shawn Bayern
JSTL in Action http://www.jstlbook.com
--
To unsubscribe, e-mail: mailto:taglibs-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:taglibs-user-help;jakarta.apache.org
Re: Does JSTL XML taglibs ignore XMLNamespace of input document?
On Fri, 18 Oct 2002 [EMAIL PROTECTED] wrote: I have worked out about this issue and I believe I have got an idea of betterment to the jakarta standard taglibs1.0.x and possibly to the JSTL specification. Here I refrain the initial issue I raised just to remind it. I coded the following JSP page Sorry, I saw this the first time around, but it slipped through my mailbox because I was away at a conference. The issue isn't JSTL's, at least not directly. You're just not using XPath correctly. Consider your example: - %@ taglib uri=/WEB-INF/x.tld prefix=x % x:parse var=NoNSabboon/b/a/x:parse x:parse var=WithNSn:a xmlns:n =someNamespacen:bbaan/n:b/n:a/x:parse $NoNS/a/b=x:out select=$NoNS/a/b/br $WithNS/a/b=x:out select=$WithNS/a/b/br $WithNS/n:a/n:b=x:out select=$WithNS/n:a/n:b/ Here, both documents are parsed correctly and available for your use. However, the XPath expressions that you're using against the document that uses namespaces are incorrect. In XPath, n:a is not a valid step; it does not refer, as you seem to be expecting, to the node named 'a' in the namespace identified by prefix 'n'. If you want to refer to this node, you'll probably want to use the name() and namespace-uri() functions in XPath. See the XPath standard or chapter 8 of JSTL in Action. -- Shawn Bayern JSTL in Action http://www.jstlbook.com -- To unsubscribe, e-mail: mailto:taglibs-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:taglibs-user-help;jakarta.apache.org
Re: might have found a bug in jslt 1.0.2
On Fri, 18 Oct 2002, peter lin wrote: it's only when the syntax is incorrect that it doesn't throw an exception like symbol cannot be resolved, clascastexception or some other exception. Right or wrong, I expect the EL to realize duh, that's the wrong syntax silly pete. I'm throwing an exception. Which EL expression causes this? If the syntax of an expression isn't parseable, the EL should throw an exception. If the property is simply unknown, the behavior can depend on whether we're dealing with a Map or JavaBean; it's all defined by the spec. Since our JSTL implementation doesn't directly produce logs, I'm just trying to figure out *exactly* what you're doing that does produce logs, and then trace it back to the code that ultimately causes them to be created. Ideally, you'd have a minimal pair of two *identical* fragments, one of which uses the EL and produces the erroneous logs, and one of which doesn't. Sorry if I'm being obtuse; I'm just not understanding the problem reports, or I'm missing some information. Shawn -- To unsubscribe, e-mail: mailto:taglibs-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:taglibs-user-help;jakarta.apache.org
