I hadn't gotten much of an answer to the question I asked, but I did make some headway with the EL language. I'm thinking of sending the comments that I came up with to the JSR list, as a "first timer's experience", but I thought I would post them here for everyone to peruse.
Some of the problems were more my own lack of understanding, or assumptions, and some could be the particular implementation.
To start with, the variables used in the EL are not your standard java variables, as given in the crude figure. The attributes are closer to the browser variables sent up in the transaction. (They are actually in separate maps from the request vars., but are basically the same concept.)
+==========+========+==========+
| | ! |
|Java | Browser Variables |
|Variables | ! |
| | ! |
| | ! |
| | in ! in |
| | Servlet! Client |
| | ! |
| | ! |
+==========+========+==========+
^
|
JSTL |
"Attributes"
stored here<[EMAIL PROTECTED] import="java.util.Locale,java.util.TimeZone" session="false"%> <[EMAIL PROTECTED] uri="http://java.sun.com/jstl/core"; prefix="c" %> <% /* NOTE: this is a test program. Why one would do what I am doing is not in * question. It is the experience with the tags that really counts. */
/* There turned out to be two major problems with using the EL tags in this
* example.
*
* 1) The classes I was interested in using were static, so they cannot
* be instantiated as Javabeans using <jsp:useBean ...>
*
* 2) There doesn't seem to be a way to access the functions of an object
* using EL language. This means that I needed to do a lot of array
* building (or List, etc.) since Locale returns a array of Locale objects.
* It would have been nice to be able to call ${locale.getCountry()} on
* each item in the returned array. Instead I needed to do this ahead of
* time using a String array.
*/ String t[] = TimeZone.getAvailableIDs();
java.util.Arrays.sort(t);
pageContext.setAttribute("zones", t, PageContext.APPLICATION_SCOPE); Locale [] localeInfo = Locale.getAvailableLocales();
String info[][] = new String[localeInfo.length][3];
for (int x = 0; x < localeInfo.length; x++) {
info[x][0] = localeInfo[x].getLanguage();
info[x][1] = localeInfo[x].getCountry();
info[x][2] = localeInfo[x].getDisplayName();
} /* we used "curr-locale", "curr-locale-lang", etc. which worked, but caused
* an error when it came time to evaluate. The processor was
* convinced that the variable was a Long, and not a String. Not a good
* error and a real problem to debug. It would be nice if the
* setAttribute() call failed with an "illegal name" or something.
*/ pageContext.setAttribute("locales", info, PageContext.PAGE_SCOPE);
pageContext.setAttribute("currLocale", Locale.getDefault().getLanguage() + "_"
+ Locale.getDefault().getCountry(), PageContext.PAGE_SCOPE);
pageContext.setAttribute("currLocaleLang", Locale.getDefault().getLanguage(),
PageContext.PAGE_SCOPE);
pageContext.setAttribute("currLocaleCo", Locale.getDefault().getCountry(),
PageContext.PAGE_SCOPE);
pageContext.setAttribute("currTZ", TimeZone.getDefault().getID(),
PageContext.PAGE_SCOPE);
%>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd";>
<html>
<head><title>Test page</title>
<style type="text/css">
TD { text-align: left; vertical-align: top; }
TH { text-align: left; vertical-align: top; }
</style>
</head>
<body>
<h1>Available locales on this user's computer:</h1>
<form action="">
<input type="submit" value="set"/><br/>
<!--
Just a few values for testing. Debugging the tags can be a pain,
perhaps not much worse than plain JSP, but the complete loss
of static variable analysis is a major pain.<c:out value="${currLocale}"/><br/>
<c:out value="${currLocaleLang}"/><br/>
<c:out value="${currLocaleCo}"/><br/>
<c:out value="${testtest}"/><br/>
-->
<table>
<tr>
<th>Locales</th>
<th>TimeZones</th>
</tr>
<tr>
<td>
<%--
One of the real problems on Tomcat is the "Unterminated tag" exception that comes
up constantly. Without knowing what tag is open, this can take a huge amount
of time to debug. (foreach instead of forEach was a huge pain!)
--%>
<c:forEach items="${locales}" var="locale">
<%-- Doh! Can't use <c:if ...>, becuase there isn't a <c:else ...>. --%>
<c:choose>
<c:when test="${locale[0] == currLocaleLang and locale[1] == currLocaleCo}">
<%--
A major bit of confusion for shell scripters. The ${} construct turned out unexpected.
It is not the variable which goes in the curly braces, but instead the entire
expression.
Originally tried to test ${locale[0]}_${locale[1]} == ${curr-locale}, but this didn't
work;
Neither did "${(locale[0] '_' locale[1]) == currLocale}" nor
"${(locale[0] + '_' + locale[1]) == currLocale}"
--%> <input type="radio" name="LOC" value="<c:out value="${locale[0]}_${locale[1]}"/>"
checked>
</c:when>
<c:otherwise>
<input type="radio" name="LOC" value="<c:out value="${locale[0]}_${locale[1]}"/>">
</c:otherwise>
</c:choose><c:out value="${locale[2]}"/><br>
</c:forEach>
</td>
<td>
<c:forEach items="${zones}" var="zone">
<c:choose>
<c:when test="${zone == currTZ}">
<input type="radio" name="TZ" value="${zone}" checked>
</c:when>
<c:otherwise>
<input type="radio" name="TZ" value="${zone}">
</c:otherwise>
</c:choose><c:out value="${zone}"/><br>
</c:forEach>
</td>
</tr>
</table>
</form>
</body>
</html>Eric Noriega wrote:
So I've been trying to use the JSTL tags in order to create a few simple pages. One of these accesses the current Time Zones (using java.util.TimeZone.getAvailableIDs() ) and then proceeds to print them out in a form w/ a radio button. I have a few problem most of which stems from a poor understanding of the binding between Java objects and the expression language variables. My question is, is there a binding at all? TimeZone is a static class, so I can't create an instance of it as a bean. I can't use <c:set ... /> to set the property either, since it seems that the EL variables are not true java variables.
<thoughtful rant> I'm obviously not getting something. It seems like the EL is about hiding the best part of Java, which is the language itself. I've seen a couple of posts about using PHP instead of JSP. If this is any indication of the direction, I'm not sure why a person wouldn't. If it 's going to look like PHP anyway, what's the point? Perhaps we should stop making pages that HTML designers can easily update and hire some more programers who have a clue. </thoughtful rant>
Any examples welcome. Thanks . . .
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST". For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST".
Some relevant archives, FAQs and Forums on JSPs can be found at:
http://java.sun.com/products/jsp http://archives.java.sun.com/jsp-interest.html http://forums.java.sun.com http://www.jspinsider.com
=========================================================================== To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST". For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST".
Some relevant archives, FAQs and Forums on JSPs can be found at:
http://java.sun.com/products/jsp http://archives.java.sun.com/jsp-interest.html http://forums.java.sun.com http://www.jspinsider.com
